From lint@h3c.com Tue Aug 4 02:41:19 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218DB3A6FDF for ; Tue, 4 Aug 2009 02:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.121 X-Spam-Level: **** X-Spam-Status: No, score=4.121 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_63=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMPvupr-gWGH for ; Tue, 4 Aug 2009 02:41:10 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id 5029A3A6FF3 for ; Tue, 4 Aug 2009 02:41:07 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KNU00IG3IL4RE@h3cml01-in.huawei-3com.com> for savi@ietf.org; Tue, 04 Aug 2009 17:34:16 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KNU00CRMIL4SS@h3cml01-in.huawei-3com.com> for savi@ietf.org; Tue, 04 Aug 2009 17:34:16 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.15]) by smtp1.h3c.com with ESMTP; Tue, 04 Aug 2009 17:41:03 +0800 Date: Tue, 04 Aug 2009 17:34:12 +0800 From: Lin Tao To: Eric Levy-Abegnoli , Erik Nordmark Message-id: <009701ca14e6$ba6debc0$0f11990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <21507DAB-FC6E-4651-8672-90327657C368@ericsson.com> <4A6EBD8B.8000607@sun.com> <4A6EE179.4080400@cisco.com> <4A6F189F.1050206@sun.com> <4A6F555D.6070806@cisco.com> Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Consensus call on "unregistered" source addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 09:41:19 -0000 SGVsbG8sIEV2ZXJ5b25lIQ0KDQpJJ20gU29ycnksIEkgaGF2bid0IHRha2VuIHBhcnQgaW4gdGhl IHNpZ25pZmljYW50IGRpc2N1c3MgZm9yIG1hbnkgbW9udGhzLg0KDQpJIGFncmVlIEVyaWMncyB2 aWV3cG9pbnQgdGhhdCB0aGUgZmlyc3QgTDIgc3dpdGNoIHNob3VsZCBiZSBzYXZpLWZvY3VzIHN3 aXRjaC4NClRoZSBjb21wbGV0ZWx5IHRoZW9yaXRpY2FsIHByb2JsZW0gaW4gbW9zdCBlbnZpcm9u bWVudHMgYWxzbyBzaG91bGQgYmUgc29sdmUNCmluIHRoZSBmdXR1cmUsIGJ1dCBub3Qgbm93LiBJ UHY2IG11c3QgaGF2ZSBsb3cgY29zdCBhbmQgZWFzeSBpbXBsZW1lbnRhdGlvbg0KaW4gTDIgc3dp dGNoLg0KDQpJIHdvbmRlciB0aGF0IFdoeSBzaG91bGQgIHdlIGNvbnNpZGVyIHRoZSB1bnJlZ2lz dGVyZWQgc291cmNlIGFkZHJlc3Nlcy4NCklmIHRoZXNlIGFkZHJlc3NlcyBpcyBwZXJtaXQsIFdo eSBkaWQgd2UgY3JlYXRlIHRoZSBiaW5kaW5nIHRhYmxlPw0KDQpBbmQgSSB3b25kZXIgdGhhdCBX aHkgc2hvdWxkIHRoZSBmaXJzdCBkYXRhIHBhY2tldChub3QgY29udHJvbCBwYWNrZXQpDQp0cmln Z2VyIGJpbmRpbmcgcHJvY2Vzcy4gSWYgdGhpcyBkYXRhIGlzIHBlcm1pdCwgaG93IGRvZXMgdGhl IHN3aXRjaCBBU0lDIA0KYmUgc2V0IGluIHRoZSBpbnB1dCBwcm9jZXNzPyBIb3cgdG8gc2V0IGEg cGFja2V0IGhhc24ndCBtZXQgYW55IHNvdXJjZQ0KZmlsdGVyIEFDTCB0byBzZW5kIHRvIENQVT8N Cg0KQ291bGQgYW55b25lIHJlbGVhc2UgbWUgZnJvbSB0aGVzZSBwdXp6bGU/IFRoYW5rIHlvdSB2 ZXJ5IG11Y2guDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiRXJpYyBM ZXZ5LUFiZWdub2xpIiA8ZWxldnlhYmVAY2lzY28uY29tPg0KVG86ICJFcmlrIE5vcmRtYXJrIiA8 ZXJpay5ub3JkbWFya0BzdW4uY29tPg0KQ2M6ICJTQVZJIE1haWxpbmcgTGlzdCIgPHNhdmlAaWV0 Zi5vcmc+OyAiQ2hyaXN0aWFuIFZvZ3QiIDxjaHJpc3RpYW4udm9ndEBlcmljc3Nvbi5jb20+DQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMDkgMzo0NSBBTQ0KU3ViamVjdDogUmU6IFtzYXZp XSBDb25zZW5zdXMgY2FsbCBvbiAidW5yZWdpc3RlcmVkIiBzb3VyY2UgYWRkcmVzc2VzDQoNCg0K RXJpayBOb3JkbWFyayBhIOljcml0IDoNCj4gRXJpYyBMZXZ5LUFiZWdub2xpIHdyb3RlOg0KPj4g RXJpaywNCj4+IEVyaWsgTm9yZG1hcmsgYSDpY3JpdCA6DQo+Pj4gQ2hyaXN0aWFuIFZvZ3Qgd3Jv dGU6DQo+Pj4+IEZvbGtzIC0NCj4+Pj4NCj4+Pj4gQXMgYW5ub3VuY2VkIGVhcmxpZXIsIHdlIHdp bGwgaGF2ZSBhIGNvbnNlbnN1cyBjYWxsIG9uIGhvdyBTQVZJIA0KPj4+PiBkZXZpY2VzDQo+Pj4+ IHNob3VsZCB0cmVhdCBzb3VyY2UgYWRkcmVzc2VzIGZvciB3aGljaCBubyBjb25maWd1cmF0aW9u IHNpZ25hbGluZyB3YXMNCj4+Pj4gc2Vlbi4gIENvbnNlbnN1cyBxdWVzdGlvbnMgZm9yIHRoaXMg d2VyZSBwcm9wb3NlZCBvbiBKdWx5IDgsIGFuZCB0aGUNCj4+Pj4gZmVlZGJhY2sgcmVjZWl2ZWQg ZnJvbSB0aGUgd29ya2luZyBncm91cCBpbmRpY2F0ZXMgdGhhdCB0aG9zZSBhcmUgT0suDQo+Pj4+ DQo+Pj4+IEkgd291bGQgaGVuY2UgbGlrZSB0byBpbml0aWF0ZSB0aGUgY29uc2Vuc3VzIGNhbGwu ICBUbyBwYXJ0aWNpcGF0ZSBpbg0KPj4+PiB0aGUgY29uc2Vuc3VzIGNhbGwsIHBsZWFzZSBhbnN3 ZXIgYnkgU3VuZGF5LCBKdWx5IDE5LCB0aGUgZm9sbG93aW5nIA0KPj4+PiB0d28NCj4+Pj4gcXVl c3Rpb25zIChBKSBhbmQgKEIpLCB1c2luZyBvbmUgb2YgdGhlIHR3byBwb3NzaWJsZSBhbnN3ZXJz IHByb3ZpZGVkDQo+Pj4+IGZvciBlYWNoIHF1ZXN0aW9uOg0KPj4+Pg0KPj4+PiAoQSkgSW4gbmV0 d29ya3Mgd2hlcmUgU0xBQUMgaXMgcGVybWl0dGVkIGZvciBhZGRyZXNzIGNvbmZpZ3VyYXRpb24s IA0KPj4+PiBob3cNCj4+Pj4gICAgIHNob3VsZCBhIFNBVkkgZGV2aWNlIHRyZWF0IHBhY2tldHMg d2l0aCBhIHNvdXJjZSBhZGRyZXNzIGZvciB3aGljaA0KPj4+PiAgICAgbmVpdGhlciBhIHN1Y2Nl c3NmdWwgREFEIHByb2NlZHVyZSBub3IgYSBESENQIGFzc2lnbm1lbnQgd2FzIHNlZW4/DQo+Pj4+ DQo+Pj4+ICAgICAoQTEpIERpc2NhcmQgdGhlIHBhY2tldA0KPj4+PiAgICAgKEEyKSBGb3J3YXJk IGFuZCBvcHRpb25hbGx5IGxvZyB0aGUgcGFja2V0DQo+Pj4NCj4+PiBJIHRoaW5rIHRoZSBxdWVz dGlvbiB3YXMgbWFsZm9ybWVkIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnMuDQo+Pj4NCj4+PiAq SUYqIFNMQUFDIGlzIHBlcm1pdHRlZCwgdGhlbiBieSBkZWZpbml0aW9uIHRoZSBob3N0IGNhbiBw aWNrIA0KPj4+IHdoYXRldmVyIGFkZHJlc3MgaXQgd2FudHMuIERBRCBhcyBkZWZpbmVkIGlzIG5v dCBhIHJlbGlhYmxlIA0KPj4+IHByb3RvY29sLCB0aHVzIHByZXRlbmRpbmcgaXQgaXMgdGhlIHdh eSBhIGhvc3QgKnJlZ2lzdGVycyogYSBTTEFBQyANCj4+PiBhZGRyZXNzIG1ha2VzIG5vIHNlbnNl LiBGb3IgaW5zdGFuY2UsIGlmIDgwMi4xRCBicmlkZ2VzIHdhaXQgZm9yIDMwIA0KPj4+IHNlY29u ZHMgYmVmb3JlIGVuYWJsaW5nIGEgRXRoZXJuZXQgcG9ydCwgdGhlbiBubyBEQUQgcGFja2V0IHdv dWxkIGJlIA0KPj4+IHNlZW4gb24gdGhlIG5ldHdvcmsuDQo+Pj4NCj4+PiBUaHVzIEkgdGhpbmsg dGhlIGNhc2Ugd2hlbiB0aGUgdGhlIGFkbWluIHdhbnRzIHRvIG9ubHkgYWxsb3cgDQo+Pj4gcmVn aXN0ZXJlZCBhZGRyZXNzZXMgdGhlbiBTTEFBQyBjYW4gbm90IGJlIHVzZWQ7IERIQ1B2NiB3b3Vs ZCBuZWVkIA0KPj4+IHRvIGJlIHVzZWQgYXMgdGhlIGFzc2lnbm1lbnQvcmVnaXN0cmF0aW9uIHBy b3RvY29sLg0KPj4+DQo+PiBNYXliZSBpdCdzIGEgbWF0dGVyIG9mIHdvcmRpbmcuIEluIHRoZSBT TEFDQyBjYXNlLCB0aGUgaG9zdCBkb2VzIG5vdCANCj4+ICpyZWdpc3RlciosICBob3dldmVyIGl0 IGlzIG5vdCB1bnJlYXNvbm5hYmxlIHRvIGV4cGVjdCB0aGF0IHRoZSBmaXJzdCANCj4+IGhvcCAo TDIgc3dpdGNoKSAgaGF2ZSBzZWVuIGEgYmluZGluZyBmb3IgaXQuDQo+DQo+IFdoaWNoIHByb3Rv Y29sIHJlbGlhYmx5IGVzdGFibGlzaGVkIHRoYXQgYmluZGluZz8NCkRpZCB5b3UgcmVhZCAicmVs aWFibHkgZXN0YWJsaXNoZWQiPyBOb25lLCBzbz8gV2UgY2FuIHNwZW5kIHllYXJzIA0Kc29sdmlu ZyBhIHByb2JsZW0gdGhhdCBpcyBhIGNvbXBsZXRlbHkgdGhlb3JpdGljYWwgcHJvYmxlbSBpbiBt b3N0IA0KZW52aXJvbm1lbnRzLiBPciB3ZSBjYW4gdHJ5IHRvIGRvIHdpdGggd2hhdCB3ZSBoYXZl Lg0KREFEIGlzIHRoZW9yaXRpY2FsbHkgYnJva2VuLiBJIG1lYW4gREFELCBubyBzYXZpLiBJZiB5 b3VyIERBRCBwYWNrZXQgaXMgDQpsb3N0LCB5b3UgbmV2ZXIga25vdyB0aGF0IHlvdXIgYWRkcmVz cyBpcyBkdXBsaWNhdGUuIC0gaW4gdGhlb3J5LCBpdCANCmNvdWxkIGJlLSAqZXhhY3RseSogaW4g dGhlIGNhc2UgdGhhdCB5b3UgZGVzY3JpYmUgYmVsb3csIHlvdSBkb24ndCBrbm93IA0KbmVpdGhl ci4gRG9lcyB0aGF0IHByZXZlbnQgbm9kZSB0byB0ZXN0IGR1cGxpY2F0ZSBpbiBtb3N0IGNhc2Vz PyBuby4NCkl0IHdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgYSBkZWNsYXJhdGl2ZSByZWxpYWJsZSBw cm90b2NvbC4gTm90IHN1cmUgd2UgDQpuZWVkIHlldCBhbm90aGVyIG9uZSB0aG91Z2guIEludmVy c2VORCB3b3VsZCBkby4gQnV0IHRoZSB0cnV0aCBpcywgDQpnZXR0aW5nIGFueXRoaW5nIGxpa2Ug dGhpcyBpbnRvIHRoZSBob3N0IGlzIGdvaW5nIHRvIHRha2UgYSBkZWNhZGUsIGFuZCANCm9ubHkg aWYgdGhlcmUgaXMgYSBidXlvdXQuIEkgZmluZCB0aGUgY2hhcnRlciB2ZXJ5IHdpc2UgZnJvbSB0 aGF0IA0KcmVnYXJkOiBubyBuZXcgcHJvdG9jb2wgYWxsb3dlZC4NCiANCj4NCj4+IEluIGEgc2Vu c2UsIGl0J3Mgbm90IHZlcnkgZGlmZmVyZW50IGZyb20gUlBGLiBJZiB5b3UgZG9uJ3QgaGF2ZSBh IA0KPj4gcmV0dXJuIHBhdGggdG8gaXQsIGl0IGlzIHN1c3BpY2lvdXMuIE5vdCBicm9rZW4gYmVj YXVzZSB0aGUgbmV4dGhvcCANCj4+IHdpbGwgZG8gYWRkcmVzcyByZXNvbHV0aW9uIG9uIHRoZSBy ZXZlcnNlIHBhdGgsIGJ1dCBzdXNwaWNpb3VzIA0KPj4gYmVjYXVzZSBiaW5kaW5ncyBhcmUgYW5u b3VuY2VkIGluIGEgZmFpcmx5IHJlZHVuZGFudCB3YXkgKERBRCAqIG4sIA0KPj4gTkEsIE5TKjMp DQo+DQo+IFN0YW5kYXJkIElQdjYgREFEIGRvZXMgMSBEQUQgcHJvYmUgYW5kIG5vdGhpbmcgbW9y ZS4NCj4gVGhlIHByb3Bvc2FsIEkndmUgc2VlbiBpcyB0byBvbmx5IHJlbHkgb24gdGhhdCBEQUQg cHJvYmUuDQo+DQpPbmUgREFEIGlzIHRoZSBkZWZhdWx0LC5jZXJ0YWlubHkgbm90IGEgTVVTVC4g U28gSSBkb24ndCBzZWUgYW55dGhpbmcgDQp3cm9uZyBpbiByZWNvbWVtbmRpbmcgdG8gdXNlIGEg aGlnaGVyIHZhbHVlIGluIGEgc2F2aSBzZXR1cC4gQXMgZmFzIGFzIA0KdXNpbmcgbW9yZSB0aGFu IERBRCwgd2VsbCwgaXQncyBzdGlsbCBvcGVuZWQsIGlzbid0IGl0Pw0KPj4gSXQgcmVhbGx5IHRh a2VzIHNvbWUgc3BlY2lmaWMgY2FzZXMgdG8gbm90IHNlZSBhbnkgYmluZGluZyBwcmlvciB0byAN Cj4+IGZvcndhcmQgYSBob3N0IHRyYWZmaWMuIEFuZCB0aGVuIGl0J3MgYSBtYXR0ZXIgb2YgcG9s aWN5OiBZb3VyIA0KPj4gZXhhbXBsZSBpcyB0aGUgb25lIG9mIGEgbm9uLXNhdmkgc3dpdGNoICh5 b3VyIDgwMi4xRCBicmlkZ2UpIA0KPj4gY29ubmVjdGVkIHRvIGEgc2F2aSBzd2l0Y2guIFRoZSBw b2xpY3kgY291bGQgYmUgdG8gZm9yd2FyZCBieSBkZWZhdWx0IA0KPj4gaW4gdGhpcyBjYXNlLg0K Pg0KPiBNeSBwcmltYXJ5IGV4YW1wbGUgaXMgU0FWSS84MDIuMUQgc3dpdGNoZXMgd2hpY2ggbGVh dmUgdGhlIHBvcnQgaW4gDQo+IGJsb2NrZWQgb3IgbGVhcm5pbmcgc3RhdGUgZm9yIGEgd2hpbGUg dGhlcmVieSBkcm9wcGluZyB0aGUgREFEIHByb2JlLg0KPg0KPiBGb3IgdGhlIGNhc2Ugd2hlcmUg dGhlcmUgaXMgYSBsZWdhY3kgc3dpdGNoIGJldHdlZW4gdGhlIGhvc3QgYW5kIHRoZSANCj4gU0FW SSBzd2l0Y2ggSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIGNvbXBsZXRlbHkgZGlzYWJsZSBTQVZJ OyB0aGF0IA0KPiB3b3VsZCBzZXZlcmVseSBsaW1pdCB0aGUgdXRpbGl0eSBvZiBTQVZJIChhbmQg SSByZWFsbHkgd2FudCB0byBzZWUgDQo+IFNBVkkgZW5hYmxlZCBieSBkZWZhdWx0IGV2ZXJ5d2hl cmUpIGluIGNvbW1vbiB0b3BvbG9naWVzLiBGb3IgaW5zdGFuY2UgDQo+IGNvcnBvcmF0ZSBJVCBv cmdhbml6YXRpb25zIHRoYXQgZGUtZmFjdCBlbmNvdXJhZ2UgZm9sa3MgdG8gaGF2ZSBzbWFsbCAN Cj4gdW5tYW5hZ2VkIHN3aXRjaGVzIGluIHRoZWlyIG9mZmljZSBieSBjaGFyZ2luZyBwZXIgRXRo ZXJuZXQgZHJvcC4NCj4NCj4gSSB0aGluayB0aGUgV0cgc2hvdWxkIGZpZ3VyZSBvdXQgaG93IHRv IGhhbmRsZSBzdWNoIGNhc2VzIGluIGEgcm9idXN0IA0KPiBtYW5uZXIuDQpJIGFtIG5vdCBydWxp bmcgdGhhdCBvdXQuIEJ1dCBhIG5vbi1zYXZpIHN3aXRjaCwgbm90IGRvaW5nIA0KYXV0aGVudGlj YXRpb24gYXQgbGF5ZXIyLCBjb25uZWN0ZWQgdG8gYSBzYXZpIHN3aXRjaCBpcyB0aGUgaGFyZCBj YXNlLiBJIA0Kd291bGQgbm90IHByZS1yZXEgc29sdmluZyBpdCB0byBtYWtlIHByb2dyZXNzIG9u IHRoZSBvdGhlciBjYXNlcy4NCkVyaWMNCj4NCj4gICAgRXJpaw0KPg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2F2aSBtYWlsaW5nIGxpc3QNCnNh dmlAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2F2aQ0K From junbi@cernet.edu.cn Tue Aug 4 07:00:48 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A618D3A67F8 for ; Tue, 4 Aug 2009 07:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLZdiUechPTC for ; Tue, 4 Aug 2009 07:00:47 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 0E79528C402 for ; Tue, 4 Aug 2009 07:00:45 -0700 (PDT) Received: from userPC([59.66.24.29]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm3c4a7885a1; Tue, 04 Aug 2009 22:00:33 +0800 Message-ID: <10550C64AA7A4F219822EAF91A6A2385@userPC> From: "Jun Bi" To: "Lin Tao" , "Eric Levy-Abegnoli" , "Erik Nordmark" References: <21507DAB-FC6E-4651-8672-90327657C368@ericsson.com><4A6EBD8B.8000607@sun.com> <4A6EE179.4080400@cisco.com><4A6F189F.1050206@sun.com> <4A6F555D.6070806@cisco.com> <009701ca14e6$ba6debc0$0f11990a@h3c.huawei3com.com> In-Reply-To: <009701ca14e6$ba6debc0$0f11990a@h3c.huawei3com.com> Date: Tue, 4 Aug 2009 22:00:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: cDH9U8WB Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Consensus call on "unregistered" source addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 14:00:48 -0000 Hi Tao, Thank you for your message. The advice from equipment vendors are valuable. I heard from another engineer that in current Ethernet switch structure, there are two tables: 1)first table is used to snoop packets for CPU actions (named as slow path: to send matched packets to CPU). The table size is usually smaller (because it only needs to match speified L2/L3 protocol type,and total number of ptotocol types is limited etc) 2)If the packet doesn't match the first table, then the packet will be handled in the fast path for forwarding, then before the acutal forwarding, the 2nd table is used for data packets filtering. The table size is usually longer.(because the IP,MAC, etc has to been searched here). They think if the the first table is used for data packet triggered CPU actions (if uses the 2nd table could be only used in fast path to trigger the packet dropping, there will be no slow path to send the packet to CPU here), then the source address must be installed into the first table,then the total number of source address could be bound will be reduced (because the size limitation of the first table). thanks, Jun ----- Original Message ----- From: "Lin Tao" To: "Eric Levy-Abegnoli" ; "Erik Nordmark" Cc: "SAVI Mailing List" ; "Christian Vogt" Sent: Tuesday, August 04, 2009 5:34 PM Subject: Re: [savi] Consensus call on "unregistered" source addresses Hello, Everyone! I'm Sorry, I havn't taken part in the significant discuss for many months. I agree Eric's viewpoint that the first L2 switch should be savi-focus switch. The completely theoritical problem in most environments also should be solve in the future, but not now. IPv6 must have low cost and easy implementation in L2 switch. I wonder that Why should we consider the unregistered source addresses. If these addresses is permit, Why did we create the binding table? And I wonder that Why should the first data packet(not control packet) trigger binding process. If this data is permit, how does the switch ASIC be set in the input process? How to set a packet hasn't met any source filter ACL to send to CPU? Could anyone release me from these puzzle? Thank you very much. ----- Original Message ----- From: "Eric Levy-Abegnoli" To: "Erik Nordmark" Cc: "SAVI Mailing List" ; "Christian Vogt" Sent: Wednesday, July 29, 2009 3:45 AM Subject: Re: [savi] Consensus call on "unregistered" source addresses Erik Nordmark a écrit : > Eric Levy-Abegnoli wrote: >> Erik, >> Erik Nordmark a écrit : >>> Christian Vogt wrote: >>>> Folks - >>>> >>>> As announced earlier, we will have a consensus call on how SAVI >>>> devices >>>> should treat source addresses for which no configuration signaling was >>>> seen. Consensus questions for this were proposed on July 8, and the >>>> feedback received from the working group indicates that those are OK. >>>> >>>> I would hence like to initiate the consensus call. To participate in >>>> the consensus call, please answer by Sunday, July 19, the following >>>> two >>>> questions (A) and (B), using one of the two possible answers provided >>>> for each question: >>>> >>>> (A) In networks where SLAAC is permitted for address configuration, >>>> how >>>> should a SAVI device treat packets with a source address for which >>>> neither a successful DAD procedure nor a DHCP assignment was seen? >>>> >>>> (A1) Discard the packet >>>> (A2) Forward and optionally log the packet >>> >>> I think the question was malformed for the following reasons. >>> >>> *IF* SLAAC is permitted, then by definition the host can pick >>> whatever address it wants. DAD as defined is not a reliable >>> protocol, thus pretending it is the way a host *registers* a SLAAC >>> address makes no sense. For instance, if 802.1D bridges wait for 30 >>> seconds before enabling a Ethernet port, then no DAD packet would be >>> seen on the network. >>> >>> Thus I think the case when the the admin wants to only allow >>> registered addresses then SLAAC can not be used; DHCPv6 would need >>> to be used as the assignment/registration protocol. >>> >> Maybe it's a matter of wording. In the SLACC case, the host does not >> *register*, however it is not unreasonnable to expect that the first >> hop (L2 switch) have seen a binding for it. > > Which protocol reliably established that binding? Did you read "reliably established"? None, so? We can spend years solving a problem that is a completely theoritical problem in most environments. Or we can try to do with what we have. DAD is theoritically broken. I mean DAD, no savi. If your DAD packet is lost, you never know that your address is duplicate. - in theory, it could be- *exactly* in the case that you describe below, you don't know neither. Does that prevent node to test duplicate in most cases? no. It would be great to have a declarative reliable protocol. Not sure we need yet another one though. InverseND would do. But the truth is, getting anything like this into the host is going to take a decade, and only if there is a buyout. I find the charter very wise from that regard: no new protocol allowed. > >> In a sense, it's not very different from RPF. If you don't have a >> return path to it, it is suspicious. Not broken because the nexthop >> will do address resolution on the reverse path, but suspicious >> because bindings are announced in a fairly redundant way (DAD * n, >> NA, NS*3) > > Standard IPv6 DAD does 1 DAD probe and nothing more. > The proposal I've seen is to only rely on that DAD probe. > One DAD is the default,.certainly not a MUST. So I don't see anything wrong in recomemnding to use a higher value in a savi setup. As fas as using more than DAD, well, it's still opened, isn't it? >> It really takes some specific cases to not see any binding prior to >> forward a host traffic. And then it's a matter of policy: Your >> example is the one of a non-savi switch (your 802.1D bridge) >> connected to a savi switch. The policy could be to forward by default >> in this case. > > My primary example is SAVI/802.1D switches which leave the port in > blocked or learning state for a while thereby dropping the DAD probe. > > For the case where there is a legacy switch between the host and the > SAVI switch I don't think we want to completely disable SAVI; that > would severely limit the utility of SAVI (and I really want to see > SAVI enabled by default everywhere) in common topologies. For instance > corporate IT organizations that de-fact encourage folks to have small > unmanaged switches in their office by charging per Ethernet drop. > > I think the WG should figure out how to handle such cases in a robust > manner. I am not ruling that out. But a non-savi switch, not doing authentication at layer2, connected to a savi switch is the hard case. I would not pre-req solving it to make progress on the other cases. Eric > > Erik > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From elevyabe@cisco.com Tue Aug 4 07:37:05 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021CF28C344 for ; Tue, 4 Aug 2009 07:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1Ab0k4GfXmP for ; Tue, 4 Aug 2009 07:37:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8F95F28C360 for ; Tue, 4 Aug 2009 07:37:03 -0700 (PDT) X-Files: New Version Notification for draft-levy-abegnoli-savi-plbt-01.eml : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkAAC/kd0qQ/uCKe2dsb2JhbACaKwEBFiQGoW6IKY9hBYQY X-IronPort-AV: E=Sophos;i="4.43,321,1246838400"; d="eml'208?scan'208,208";a="46433861" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Aug 2009 14:36:33 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n74EaXbE005149 for ; Tue, 4 Aug 2009 16:36:33 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n74EaXW0010937 for ; Tue, 4 Aug 2009 14:36:33 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 16:36:34 +0200 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Aug 2009 16:36:33 +0200 Message-ID: <4A784771.6000600@cisco.com> Date: Tue, 04 Aug 2009 16:36:33 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SAVI Mailing List Content-Type: multipart/mixed; boundary="------------030404000209090706050203" X-OriginalArrivalTime: 04 Aug 2009 14:36:33.0479 (UTC) FILETIME=[F69F8570:01CA1510] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3847; t=1249396593; x=1250260593; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20New=20Version=20Notification=20for=20draft-levy -abegnoli-savi-plbt-01 |Sender:=20; bh=s2gsGCZrYf7ik8seEb6VBELI6S47p6Dm6cRGW+Ez6U8=; b=FyFbEuKWm4iIbfm6pYsOGWvmlaeTR30UNkapx7P1iHgcUD49Kci4xFSssQ vNP9ALxTvEkU8P2GjTHH5qk6lLY3A9ZbSlDlB4sYyCkjtbZNnKo43kDYN1yu l/vg40prQV; Authentication-Results: ams-dkim-1; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [savi] New Version Notification for draft-levy-abegnoli-savi-plbt-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 14:37:05 -0000 This is a multi-part message in MIME format. --------------030404000209090706050203 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have uploaded a new version of the pblt draft (draft-levy-abegnoli-savi-plbt-01) to keep only the central issues with regard to [fcfs] and the proposed resolution. It should make the document easier to review. Feedbacks are more than welcome. Document can be found at: http://www.ietf.org/id/draft-levy-abegnoli-savi-plbt-01.txt Thanks Eric --------------030404000209090706050203 Content-Type: message/rfc822; name="New Version Notification for draft-levy-abegnoli-savi-plbt-01.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-levy-abegnoli-savi-plbt-0"; filename*1="1.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-ams-102.cisco.com ([144.254.73.132]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Aug 2009 16:29:50 +0200 Received: from xbh-rtp-201.amer.cisco.com ([64.102.31.12]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 16:29:50 +0200 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 10:29:41 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Aug 2009 14:29:38 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n74ETceo027714 for ; Tue, 4 Aug 2009 10:29:38 -0400 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n74ETaDZ029703 for ; Tue, 4 Aug 2009 14:29:38 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucBAE/id0pAqmIglGdsb2JhbACPWgGKUAEBAQEJCwgJEwWhc5gQhBgF X-IronPort-AV: E=Sophos;i="4.43,321,1246838400"; d="scan'208";a="121197387" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-f.cisco.com with ESMTP; 04 Aug 2009 14:29:37 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 6F5423A706E; Tue, 4 Aug 2009 07:28:59 -0700 (PDT) From: IETF I-D Submission Tool To: elevyabe@cisco.com Subject: New Version Notification for draft-levy-abegnoli-savi-plbt-01 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090804142859.6F5423A706E@core3.amsl.com> Date: Tue, 4 Aug 2009 07:28:59 -0700 (PDT) Authentication-Results: rtp-dkim-1; header.From=idsubmission@ietf.org; dkim=neutral Return-Path: wwwrun@core3.amsl.com X-OriginalArrivalTime: 04 Aug 2009 14:29:41.0738 (UTC) FILETIME=[0134D4A0:01CA1510] A new version of I-D, draft-levy-abegnoli-savi-plbt-01.txt has been successfuly submitted by Eric Levy-Abegnoli and posted to the IETF repository. Filename: draft-levy-abegnoli-savi-plbt Revision: 01 Title: Preference Level based Binding Table Creation_date: 2009-08-04 WG ID: Independent Submission Number_of_pages: 8 Abstract: [fcfs] proposes a simple preference scheme to resolve binding entry collisions (same l3 address, different anchors): it keeps the first entry and rejects any others. However, there are cases where keeping the first entry is not the best choice, and others cases where it is bogus. This draft analyses what are these cases, and proposes a different algorithm (preference based) to fix the problem. The IETF Secretariat. --------------030404000209090706050203-- From zhangdong_rh@huaweisymantec.com Tue Aug 4 19:21:45 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00943A6F9C for ; Tue, 4 Aug 2009 19:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.545 X-Spam-Level: X-Spam-Status: No, score=0.545 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiT6LsF2YV4B for ; Tue, 4 Aug 2009 19:21:45 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id E52D03A6CB7 for ; Tue, 4 Aug 2009 19:21:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNV00LJKT81BE40@hstga02-in.huaweisymantec.com> for savi@ietf.org; Wed, 05 Aug 2009 10:21:37 +0800 (CST) Received: from z90001956 ([10.27.154.76]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KNV009TNT80AR00@hstml01-in.huaweisymantec.com> for savi@ietf.org; Wed, 05 Aug 2009 10:21:37 +0800 (CST) Date: Wed, 05 Aug 2009 10:21:36 +0800 From: Dong Zhang To: Eric Levy-Abegnoli , SAVI Mailing List References: <4A784771.6000600@cisco.com> Message-id: <200908051021361825410@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Subject: [savi] Question for draft-levy-abegnoli-savi-plbt-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 02:21:45 -0000 Hi Eric, I have a litte confusion here. >Consider the case of a link with a mix of ND (RFC4861] and SeND >(RFC3971] nodes. Consider node A running ND, node B and node C >running SeND. Can the mix of ND and SeND in a same link be a common case? I mean if this happens, how to handle the NA/NS between SeND node and non- SeND node? >The following preflevel values have been identified (from lowest to >highest): >o LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2) > are identical; >o TRUNK_PORT: the entry was learnt from a trunk port (connected to > another switch) >o ACCESS_PORT: the entry was leant from an access port (connected to > a host) >o TRUSTED_ACCESS: The entry was learnt from a trusted port >o TRUSTED_TRUNK: The entry was learnt from a trusted trunk >o DHCP_ASSIGNED: the entry is assigned by DHCP >o CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972] >o CERT_AUTHENTICATED: the entry is authenticated with a certificate >o STATIC: this is a statically configured entry per [RFC3971]. Then what about ACCESS_PORT+DHCP_ASSIGNED and TRUNK_PORT+CGA_AUTHENTICATED, which is bigger? I think there will be some different cases and combinations of the preflevel values. Is it necessary and possible to list every case, giving particular illustration? Then it will be much more clear. Perhaps I might miss something. Thank you. ------------------ Dong Zhang 2009-08-05 From gdaley@netstarnetworks.com Tue Aug 4 22:03:35 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C62128C2A6 for ; Tue, 4 Aug 2009 22:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ucybLIu+1L for ; Tue, 4 Aug 2009 22:03:34 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id F3B363A69A5 for ; Tue, 4 Aug 2009 22:03:33 -0700 (PDT) Received: from sdcmail.netstarnetworks.com ([10.18.193.12]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n7553NRs029052; Wed, 5 Aug 2009 15:03:24 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sdcmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:03:15 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 15:03:14 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918011CEF02@melmail.netstarnetworks.com> In-Reply-To: <200908051021361825410@huaweisymantec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] Question for draft-levy-abegnoli-savi-plbt-01 Thread-Index: AcoVc3/lQ/5XkTBDR0mBagqBosMF3gAFJCXw References: <4A784771.6000600@cisco.com> <200908051021361825410@huaweisymantec.com> From: "Greg Daley" To: "Dong Zhang" , "Eric Levy-Abegnoli" , "SAVI Mailing List" X-OriginalArrivalTime: 05 Aug 2009 05:03:15.0830 (UTC) FILETIME=[0A709160:01CA158A] Subject: Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 05:03:35 -0000 Hi Dong,=20 > Can the mix of ND and SeND in a same link be a common case? I mean=20 > if this happens, how to handle the NA/NS between SeND node and non- > SeND node? =20 SEND/non-SEND interoperation is dealt with extensively in RFC3971. It does make sense to have a mix of nodes on the LAN, and this allows incremental security deployment. > >The following preflevel values have been identified (from lowest to > >highest): > >o LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2) > > are identical; > >o TRUNK_PORT: the entry was learnt from a trunk port (connected to > > another switch) > >o ACCESS_PORT: the entry was leant from an access port (connected to > > a host) > >o TRUSTED_ACCESS: The entry was learnt from a trusted port > >o TRUSTED_TRUNK: The entry was learnt from a trusted trunk > >o DHCP_ASSIGNED: the entry is assigned by DHCP > >o CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972] > >o CERT_AUTHENTICATED: the entry is authenticated with a certificate > >o STATIC: this is a statically configured entry per [RFC3971]. > Then what about ACCESS_PORT+DHCP_ASSIGNED and TRUNK_PORT+CGA_AUTHENTICATED, which is bigger? > I think there will be some different cases and combinations of the preflevel=20 > values. Is it necessary and possible to list every case, giving particular=20 > illustration? Then it will be much more clear. Perhaps I might miss something. Since the bindings identify the level of authority attained about the=20 address mapping, only the highest of these should be considered. The presence of CGA_AUTHENTICATED means the higher level of certification which has been attained by the binding. This would supercede a previous (or contemporary) binding of TRUNK_PORT. Therefore the binding state would be CGA_AUTHENTICATED. Similarly, with ACCESS_PORT+DHCP_ASSIGNED, the DHCP assignment is a control process which can be authenticated and is specified by a server. This has more authority than the ACCESS_PORT binding. Therefore this binding's state is DHCP_ASSIGNED. Comparison of these bindings therefore becomes simpler: DHCP_ASSIGNED vs CGA_AUTHENTICATED Perhaps some clarifying words could be put into the draft? Please note that an address binding can be both CGA Authenticated and DHCPv6 assigned, since a node can propose its address in DHCPv6 based on known address prefixes. In this case, the fact that the device can perform SEND CGA Auth on the address lends more authority to the binding (giving CGA_AUTHENTICATED) state. Sincerely, Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 From zhangdong_rh@huaweisymantec.com Wed Aug 5 00:26:52 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3532E3A7173 for ; Wed, 5 Aug 2009 00:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZOu05j3lSph for ; Wed, 5 Aug 2009 00:26:51 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 3B5113A6A98 for ; Wed, 5 Aug 2009 00:26:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNW00IR87CJTN10@hstga01-in.huaweisymantec.com> for savi@ietf.org; Wed, 05 Aug 2009 15:26:43 +0800 (CST) Received: from z90001956 ([10.27.154.76]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KNW009G57CIQK10@hstml01-in.huaweisymantec.com> for savi@ietf.org; Wed, 05 Aug 2009 15:26:43 +0800 (CST) Date: Wed, 05 Aug 2009 15:26:43 +0800 From: Dong Zhang To: Greg Daley , Eric Levy-Abegnoli , SAVI Mailing List References: <4A784771.6000600@cisco.com> <200908051021361825410@huaweisymantec.com> <6983BF97BFC24D4EA551F14071232918011CEF02@melmail.netstarnetworks.com> Message-id: <200908051526433405468@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Subject: Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 07:26:52 -0000 Hi Greg, Greg Daley 2009-08-05 Wrote: >Hi Dong, > >> Can the mix of ND and SeND in a same link be a common case? I mean >> if this happens, how to handle the NA/NS between SeND node and non- >> SeND node? > >SEND/non-SEND interoperation is dealt with extensively in RFC3971. > >It does make sense to have a mix of nodes on the LAN, and this allows >incremental security deployment. Hmmm, if so, I might re-read RFC3971 carefully. :) > >> >The following preflevel values have been identified (from lowest to >> >highest): >> >o LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2) >> > are identical; >> >o TRUNK_PORT: the entry was learnt from a trunk port (connected to >> > another switch) >> >o ACCESS_PORT: the entry was leant from an access port (connected to >> > a host) >> >o TRUSTED_ACCESS: The entry was learnt from a trusted port >> >o TRUSTED_TRUNK: The entry was learnt from a trusted trunk >> >o DHCP_ASSIGNED: the entry is assigned by DHCP >> >o CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972] >> >o CERT_AUTHENTICATED: the entry is authenticated with a certificate >> >o STATIC: this is a statically configured entry per [RFC3971]. > >> Then what about ACCESS_PORT+DHCP_ASSIGNED and >TRUNK_PORT+CGA_AUTHENTICATED, which is bigger? >> I think there will be some different cases and combinations of the >preflevel >> values. Is it necessary and possible to list every case, giving >particular >> illustration? Then it will be much more clear. Perhaps I might miss >something. > > >Since the bindings identify the level of authority attained about the >address mapping, only the highest of these should be considered. > >The presence of CGA_AUTHENTICATED means the higher level of >certification >which has been attained by the binding. This would supercede a >previous >(or contemporary) binding of TRUNK_PORT. Therefore the binding state >would >be CGA_AUTHENTICATED. > >Similarly, with ACCESS_PORT+DHCP_ASSIGNED, the DHCP assignment is a >control process which can be authenticated and is specified by a server. >This has more authority than the ACCESS_PORT binding. Therefore this >binding's state is DHCP_ASSIGNED. > >Comparison of these bindings therefore becomes simpler: DHCP_ASSIGNED vs >CGA_AUTHENTICATED > >Perhaps some clarifying words could be put into the draft? According to your explanation, my understanding is an entry may have serveral preflevel values. And we pick up a highest one, to compare with another entry's. If my understanding is right, yse, I do suggest adding a few words to make this point much clearer. This draft provides a approach to reduce the possibility of misbinding in fcfs. That is to say the approach is used for the data packet first reveiced the savi switch. Other process is still the same with fcfs. Right? This approach adds complexity to fcfs. Need we worry about the cost? Thx. > >Please note that an address binding can be both CGA Authenticated and >DHCPv6 assigned, since >a node can propose its address in DHCPv6 based on known address >prefixes. In this case, >the fact that the device can perform SEND CGA Auth on the address lends >more authority to the >binding (giving CGA_AUTHENTICATED) state. > > >Sincerely, > >Greg Daley >Security Consultant >NetStar Australia Pty Ltd > >E-mail: gdaley@netstarnetworks.com >Mobile: +61 401 772 770 >Direct: +61 3 8532 4042 >Fax: +61 3 8532 4032 ------------------ Dong Zhang 2009-08-05 From lint@h3c.com Wed Aug 5 02:55:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DB83A6B19 for ; Wed, 5 Aug 2009 02:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.144 X-Spam-Level: **** X-Spam-Status: No, score=4.144 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=0.6, MIME_BASE64_BLANKS=0.041, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEvyhooOjxZ4 for ; Wed, 5 Aug 2009 02:55:29 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.13]) by core3.amsl.com (Postfix) with ESMTP id 7D6533A6AAA for ; Wed, 5 Aug 2009 02:55:28 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KNW00FGZDHFVG@h3cml02-in.huawei-3com.com> for savi@ietf.org; Wed, 05 Aug 2009 17:39:16 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KNW00ELPDHFRI@h3cml02-in.huawei-3com.com> for savi@ietf.org; Wed, 05 Aug 2009 17:39:15 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.15]) by smtp1.h3c.com with ESMTP; Wed, 05 Aug 2009 17:40:16 +0800 Date: Wed, 05 Aug 2009 17:33:27 +0800 From: Lin Tao To: Jun Bi , Eric Levy-Abegnoli , Erik Nordmark Message-id: <002801ca15af$c9eb46a0$0f11990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <21507DAB-FC6E-4651-8672-90327657C368@ericsson.com> <4A6EBD8B.8000607@sun.com> <4A6EE179.4080400@cisco.com> <4A6F189F.1050206@sun.com> <4A6F555D.6070806@cisco.com> <009701ca14e6$ba6debc0$0f11990a@h3c.huawei3com.com> <10550C64AA7A4F219822EAF91A6A2385@userPC> Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Consensus call on "unregistered" source addresses X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 09:55:31 -0000 VGhhbmsgeW91IHZlcnkgbXVjaC4gTWF5YmUgc29tZSBzd2l0Y2ggY2hpcCBjYW4gZG8gdGhhdCBs aWtlIHlvdSBzYXkuDQpJbiB0aGF0IHdheSwgdGhlIGNoaXAgY291bGRuJ3QgcGVyZmVjdGx5IHN1 cHBvcnQgdGhlIERhdGEgVHJpZ2dlcmVkIENQVQ0KYWN0aW9ucy4NCk9uIHRoZSBvdGhlciBoYW5k LCBJIGhhdmUgc2VlbiBkaXNjdXNzaW9uIHRoYXQgZGF0YSBwYWNrZXQgaXMgdXNlZCB0byB0cmln Z2VyZWQNCkRBRCBwcm9iZS4gSWYgdGhlIGRhdGEgdGhhdCB0cmlnZ2VyZWQgdG8gQ1BVIHRyaWdn ZXJlZCBhIERBRCBwcm9iZSwNCmFuZCB0aGUgc291cmNlIElQIGFkZHJlc3MgaXMgY29uc2lkZXJl ZCBhcyBhICBmb3JnZWQgYWRkcmVzcywgaG93IHRvIGRlYWwgDQp3aXRoIGl0PyBJZiB0aGUgQUNM IG9mIHRoaXMgc291cmNlIElQIGFkZHJlc3MgaXMgc2V0LCB0aGUgcGFja2V0IG1hdGNoIHRoaXMg QUNMDQp3aWxsIGJlIGRpc2NhcmQsIHdlIGNhbiBwcmV2ZW50IHRoZSBsYXR0ZXIgcGFja2V0IGZy b20gaW1wYWN0IHRoZSBDUFUuIEJ1dCBpdA0Kd2lsbCBvY2N1cHkgb24gQUNMIGVudHJ5IHRoYXQg aXMgZmluaXRlIHJlc291cmNlLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIkp1biBCaSIgPGp1bmJpQGNlcm5ldC5lZHUuY24+DQpUbzogIkxpbiBUYW8iIDxsaW50QGgz Yy5jb20+OyAiRXJpYyBMZXZ5LUFiZWdub2xpIiA8ZWxldnlhYmVAY2lzY28uY29tPjsgIkVyaWsg Tm9yZG1hcmsiIDxlcmlrLm5vcmRtYXJrQHN1bi5jb20+DQpDYzogIlNBVkkgTWFpbGluZyBMaXN0 IiA8c2F2aUBpZXRmLm9yZz47ICJDaHJpc3RpYW4gVm9ndCIgPGNocmlzdGlhbi52b2d0QGVyaWNz c29uLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNCwgMjAwOSAxMDowMCBQTQ0KU3ViamVj dDogUmU6IFtzYXZpXSBDb25zZW5zdXMgY2FsbCBvbiAidW5yZWdpc3RlcmVkIiBzb3VyY2UgYWRk cmVzc2VzDQoNCg0KPiANCj4gSGkgVGFvLA0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIG1lc3Nh Z2UuIFRoZSBhZHZpY2UgZnJvbSBlcXVpcG1lbnQgdmVuZG9ycyBhcmUgdmFsdWFibGUuDQo+IA0K PiBJIGhlYXJkIGZyb20gYW5vdGhlciBlbmdpbmVlciB0aGF0IGluIGN1cnJlbnQgRXRoZXJuZXQg c3dpdGNoIHN0cnVjdHVyZSwNCj4gdGhlcmUgYXJlIHR3byB0YWJsZXM6DQo+IDEpZmlyc3QgdGFi bGUgaXMgdXNlZCB0byBzbm9vcCBwYWNrZXRzIGZvciBDUFUgYWN0aW9ucyAobmFtZWQgYXMgc2xv dyBwYXRoOiANCj4gdG8gc2VuZCBtYXRjaGVkIHBhY2tldHMgdG8gQ1BVKS4gIFRoZSB0YWJsZSBz aXplIGlzIHVzdWFsbHkgc21hbGxlciAoYmVjYXVzZSANCj4gaXQgb25seSBuZWVkcyB0byBtYXRj aCBzcGVpZmllZCBMMi9MMyBwcm90b2NvbCB0eXBlLGFuZCB0b3RhbCBudW1iZXIgb2YgDQo+IHB0 b3RvY29sIHR5cGVzIGlzIGxpbWl0ZWQgZXRjKQ0KPiAyKUlmIHRoZSBwYWNrZXQgZG9lc24ndCBt YXRjaCB0aGUgZmlyc3QgdGFibGUsIHRoZW4gdGhlIHBhY2tldCB3aWxsIGJlIA0KPiBoYW5kbGVk IGluIHRoZSBmYXN0IHBhdGggZm9yIGZvcndhcmRpbmcsIHRoZW4gYmVmb3JlIHRoZSBhY3V0YWwg Zm9yd2FyZGluZywgDQo+IHRoZSAybmQgdGFibGUgaXMgdXNlZCBmb3IgZGF0YSBwYWNrZXRzIGZp bHRlcmluZy4gVGhlIHRhYmxlIHNpemUgaXMgdXN1YWxseSANCj4gbG9uZ2VyLihiZWNhdXNlIHRo ZSBJUCxNQUMsIGV0YyBoYXMgdG8gYmVlbiBzZWFyY2hlZCBoZXJlKS4NCj4gDQo+IFRoZXkgdGhp bmsgaWYgdGhlIHRoZSBmaXJzdCB0YWJsZSBpcyB1c2VkIGZvciBkYXRhIHBhY2tldCB0cmlnZ2Vy ZWQgQ1BVIA0KPiBhY3Rpb25zIChpZiB1c2VzIHRoZSAybmQgdGFibGUgY291bGQgYmUgb25seSB1 c2VkIGluIGZhc3QgcGF0aCB0byB0cmlnZ2VyIA0KPiB0aGUgcGFja2V0IGRyb3BwaW5nLCB0aGVy ZSB3aWxsIGJlIG5vIHNsb3cgcGF0aCB0byBzZW5kIHRoZSBwYWNrZXQgdG8gQ1BVIA0KPiBoZXJl KSwgdGhlbiB0aGUgc291cmNlIGFkZHJlc3MgbXVzdCBiZSBpbnN0YWxsZWQgaW50byB0aGUgZmly c3QgdGFibGUsdGhlbiANCj4gdGhlIHRvdGFsIG51bWJlciBvZiBzb3VyY2UgYWRkcmVzcyBjb3Vs ZCBiZSBib3VuZCB3aWxsIGJlIHJlZHVjZWQgKGJlY2F1c2UgDQo+IHRoZSBzaXplIGxpbWl0YXRp b24gb2YgdGhlIGZpcnN0IHRhYmxlKS4NCj4gDQo+IHRoYW5rcywNCj4gSnVuDQo+IA0KPiANCj4g LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4gRnJvbTogIkxpbiBUYW8iIDxsaW50QGgz Yy5jb20+DQo+IFRvOiAiRXJpYyBMZXZ5LUFiZWdub2xpIiA8ZWxldnlhYmVAY2lzY28uY29tPjsg IkVyaWsgTm9yZG1hcmsiIA0KPiA8ZXJpay5ub3JkbWFya0BzdW4uY29tPg0KPiBDYzogIlNBVkkg TWFpbGluZyBMaXN0IiA8c2F2aUBpZXRmLm9yZz47ICJDaHJpc3RpYW4gVm9ndCIgDQo+IDxjaHJp c3RpYW4udm9ndEBlcmljc3Nvbi5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNCwgMjAw OSA1OjM0IFBNDQo+IFN1YmplY3Q6IFJlOiBbc2F2aV0gQ29uc2Vuc3VzIGNhbGwgb24gInVucmVn aXN0ZXJlZCIgc291cmNlIGFkZHJlc3Nlcw0KPiANCj4gDQo+IEhlbGxvLCBFdmVyeW9uZSENCj4g DQo+IEknbSBTb3JyeSwgSSBoYXZuJ3QgdGFrZW4gcGFydCBpbiB0aGUgc2lnbmlmaWNhbnQgZGlz Y3VzcyBmb3IgbWFueSBtb250aHMuDQo+IA0KPiBJIGFncmVlIEVyaWMncyB2aWV3cG9pbnQgdGhh dCB0aGUgZmlyc3QgTDIgc3dpdGNoIHNob3VsZCBiZSBzYXZpLWZvY3VzIA0KPiBzd2l0Y2guDQo+ IFRoZSBjb21wbGV0ZWx5IHRoZW9yaXRpY2FsIHByb2JsZW0gaW4gbW9zdCBlbnZpcm9ubWVudHMg YWxzbyBzaG91bGQgYmUgc29sdmUNCj4gaW4gdGhlIGZ1dHVyZSwgYnV0IG5vdCBub3cuIElQdjYg bXVzdCBoYXZlIGxvdyBjb3N0IGFuZCBlYXN5IGltcGxlbWVudGF0aW9uDQo+IGluIEwyIHN3aXRj aC4NCj4gDQo+IEkgd29uZGVyIHRoYXQgV2h5IHNob3VsZCAgd2UgY29uc2lkZXIgdGhlIHVucmVn aXN0ZXJlZCBzb3VyY2UgYWRkcmVzc2VzLg0KPiBJZiB0aGVzZSBhZGRyZXNzZXMgaXMgcGVybWl0 LCBXaHkgZGlkIHdlIGNyZWF0ZSB0aGUgYmluZGluZyB0YWJsZT8NCj4gDQo+IEFuZCBJIHdvbmRl ciB0aGF0IFdoeSBzaG91bGQgdGhlIGZpcnN0IGRhdGEgcGFja2V0KG5vdCBjb250cm9sIHBhY2tl dCkNCj4gdHJpZ2dlciBiaW5kaW5nIHByb2Nlc3MuIElmIHRoaXMgZGF0YSBpcyBwZXJtaXQsIGhv dyBkb2VzIHRoZSBzd2l0Y2ggQVNJQw0KPiBiZSBzZXQgaW4gdGhlIGlucHV0IHByb2Nlc3M/IEhv dyB0byBzZXQgYSBwYWNrZXQgaGFzbid0IG1ldCBhbnkgc291cmNlDQo+IGZpbHRlciBBQ0wgdG8g c2VuZCB0byBDUFU/DQo+IA0KPiBDb3VsZCBhbnlvbmUgcmVsZWFzZSBtZSBmcm9tIHRoZXNlIHB1 enpsZT8gVGhhbmsgeW91IHZlcnkgbXVjaC4NCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQo+IEZyb206ICJFcmljIExldnktQWJlZ25vbGkiIDxlbGV2eWFiZUBjaXNjby5jb20+ DQo+IFRvOiAiRXJpayBOb3JkbWFyayIgPGVyaWsubm9yZG1hcmtAc3VuLmNvbT4NCj4gQ2M6ICJT QVZJIE1haWxpbmcgTGlzdCIgPHNhdmlAaWV0Zi5vcmc+OyAiQ2hyaXN0aWFuIFZvZ3QiIA0KPiA8 Y2hyaXN0aWFuLnZvZ3RAZXJpY3Nzb24uY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjks IDIwMDkgMzo0NSBBTQ0KPiBTdWJqZWN0OiBSZTogW3NhdmldIENvbnNlbnN1cyBjYWxsIG9uICJ1 bnJlZ2lzdGVyZWQiIHNvdXJjZSBhZGRyZXNzZXMNCj4gDQo+IA0KPiBFcmlrIE5vcmRtYXJrIGEg w6ljcml0IDoNCj4+IEVyaWMgTGV2eS1BYmVnbm9saSB3cm90ZToNCj4+PiBFcmlrLA0KPj4+IEVy aWsgTm9yZG1hcmsgYSDDqWNyaXQgOg0KPj4+PiBDaHJpc3RpYW4gVm9ndCB3cm90ZToNCj4+Pj4+ IEZvbGtzIC0NCj4+Pj4+DQo+Pj4+PiBBcyBhbm5vdW5jZWQgZWFybGllciwgd2Ugd2lsbCBoYXZl IGEgY29uc2Vuc3VzIGNhbGwgb24gaG93IFNBVkkNCj4+Pj4+IGRldmljZXMNCj4+Pj4+IHNob3Vs ZCB0cmVhdCBzb3VyY2UgYWRkcmVzc2VzIGZvciB3aGljaCBubyBjb25maWd1cmF0aW9uIHNpZ25h bGluZyB3YXMNCj4+Pj4+IHNlZW4uICBDb25zZW5zdXMgcXVlc3Rpb25zIGZvciB0aGlzIHdlcmUg cHJvcG9zZWQgb24gSnVseSA4LCBhbmQgdGhlDQo+Pj4+PiBmZWVkYmFjayByZWNlaXZlZCBmcm9t IHRoZSB3b3JraW5nIGdyb3VwIGluZGljYXRlcyB0aGF0IHRob3NlIGFyZSBPSy4NCj4+Pj4+DQo+ Pj4+PiBJIHdvdWxkIGhlbmNlIGxpa2UgdG8gaW5pdGlhdGUgdGhlIGNvbnNlbnN1cyBjYWxsLiAg VG8gcGFydGljaXBhdGUgaW4NCj4+Pj4+IHRoZSBjb25zZW5zdXMgY2FsbCwgcGxlYXNlIGFuc3dl ciBieSBTdW5kYXksIEp1bHkgMTksIHRoZSBmb2xsb3dpbmcNCj4+Pj4+IHR3bw0KPj4+Pj4gcXVl c3Rpb25zIChBKSBhbmQgKEIpLCB1c2luZyBvbmUgb2YgdGhlIHR3byBwb3NzaWJsZSBhbnN3ZXJz IHByb3ZpZGVkDQo+Pj4+PiBmb3IgZWFjaCBxdWVzdGlvbjoNCj4+Pj4+DQo+Pj4+PiAoQSkgSW4g bmV0d29ya3Mgd2hlcmUgU0xBQUMgaXMgcGVybWl0dGVkIGZvciBhZGRyZXNzIGNvbmZpZ3VyYXRp b24sDQo+Pj4+PiBob3cNCj4+Pj4+ICAgICBzaG91bGQgYSBTQVZJIGRldmljZSB0cmVhdCBwYWNr ZXRzIHdpdGggYSBzb3VyY2UgYWRkcmVzcyBmb3Igd2hpY2gNCj4+Pj4+ICAgICBuZWl0aGVyIGEg c3VjY2Vzc2Z1bCBEQUQgcHJvY2VkdXJlIG5vciBhIERIQ1AgYXNzaWdubWVudCB3YXMgc2Vlbj8N Cj4+Pj4+DQo+Pj4+PiAgICAgKEExKSBEaXNjYXJkIHRoZSBwYWNrZXQNCj4+Pj4+ICAgICAoQTIp IEZvcndhcmQgYW5kIG9wdGlvbmFsbHkgbG9nIHRoZSBwYWNrZXQNCj4+Pj4NCj4+Pj4gSSB0aGlu ayB0aGUgcXVlc3Rpb24gd2FzIG1hbGZvcm1lZCBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zLg0K Pj4+Pg0KPj4+PiAqSUYqIFNMQUFDIGlzIHBlcm1pdHRlZCwgdGhlbiBieSBkZWZpbml0aW9uIHRo ZSBob3N0IGNhbiBwaWNrDQo+Pj4+IHdoYXRldmVyIGFkZHJlc3MgaXQgd2FudHMuIERBRCBhcyBk ZWZpbmVkIGlzIG5vdCBhIHJlbGlhYmxlDQo+Pj4+IHByb3RvY29sLCB0aHVzIHByZXRlbmRpbmcg aXQgaXMgdGhlIHdheSBhIGhvc3QgKnJlZ2lzdGVycyogYSBTTEFBQw0KPj4+PiBhZGRyZXNzIG1h a2VzIG5vIHNlbnNlLiBGb3IgaW5zdGFuY2UsIGlmIDgwMi4xRCBicmlkZ2VzIHdhaXQgZm9yIDMw DQo+Pj4+IHNlY29uZHMgYmVmb3JlIGVuYWJsaW5nIGEgRXRoZXJuZXQgcG9ydCwgdGhlbiBubyBE QUQgcGFja2V0IHdvdWxkIGJlDQo+Pj4+IHNlZW4gb24gdGhlIG5ldHdvcmsuDQo+Pj4+DQo+Pj4+ IFRodXMgSSB0aGluayB0aGUgY2FzZSB3aGVuIHRoZSB0aGUgYWRtaW4gd2FudHMgdG8gb25seSBh bGxvdw0KPj4+PiByZWdpc3RlcmVkIGFkZHJlc3NlcyB0aGVuIFNMQUFDIGNhbiBub3QgYmUgdXNl ZDsgREhDUHY2IHdvdWxkIG5lZWQNCj4+Pj4gdG8gYmUgdXNlZCBhcyB0aGUgYXNzaWdubWVudC9y ZWdpc3RyYXRpb24gcHJvdG9jb2wuDQo+Pj4+DQo+Pj4gTWF5YmUgaXQncyBhIG1hdHRlciBvZiB3 b3JkaW5nLiBJbiB0aGUgU0xBQ0MgY2FzZSwgdGhlIGhvc3QgZG9lcyBub3QNCj4+PiAqcmVnaXN0 ZXIqLCAgaG93ZXZlciBpdCBpcyBub3QgdW5yZWFzb25uYWJsZSB0byBleHBlY3QgdGhhdCB0aGUg Zmlyc3QNCj4+PiBob3AgKEwyIHN3aXRjaCkgIGhhdmUgc2VlbiBhIGJpbmRpbmcgZm9yIGl0Lg0K Pj4NCj4+IFdoaWNoIHByb3RvY29sIHJlbGlhYmx5IGVzdGFibGlzaGVkIHRoYXQgYmluZGluZz8N Cj4gRGlkIHlvdSByZWFkICJyZWxpYWJseSBlc3RhYmxpc2hlZCI/IE5vbmUsIHNvPyBXZSBjYW4g c3BlbmQgeWVhcnMNCj4gc29sdmluZyBhIHByb2JsZW0gdGhhdCBpcyBhIGNvbXBsZXRlbHkgdGhl b3JpdGljYWwgcHJvYmxlbSBpbiBtb3N0DQo+IGVudmlyb25tZW50cy4gT3Igd2UgY2FuIHRyeSB0 byBkbyB3aXRoIHdoYXQgd2UgaGF2ZS4NCj4gREFEIGlzIHRoZW9yaXRpY2FsbHkgYnJva2VuLiBJ IG1lYW4gREFELCBubyBzYXZpLiBJZiB5b3VyIERBRCBwYWNrZXQgaXMNCj4gbG9zdCwgeW91IG5l dmVyIGtub3cgdGhhdCB5b3VyIGFkZHJlc3MgaXMgZHVwbGljYXRlLiAtIGluIHRoZW9yeSwgaXQN Cj4gY291bGQgYmUtICpleGFjdGx5KiBpbiB0aGUgY2FzZSB0aGF0IHlvdSBkZXNjcmliZSBiZWxv dywgeW91IGRvbid0IGtub3cNCj4gbmVpdGhlci4gRG9lcyB0aGF0IHByZXZlbnQgbm9kZSB0byB0 ZXN0IGR1cGxpY2F0ZSBpbiBtb3N0IGNhc2VzPyBuby4NCj4gSXQgd291bGQgYmUgZ3JlYXQgdG8g aGF2ZSBhIGRlY2xhcmF0aXZlIHJlbGlhYmxlIHByb3RvY29sLiBOb3Qgc3VyZSB3ZQ0KPiBuZWVk IHlldCBhbm90aGVyIG9uZSB0aG91Z2guIEludmVyc2VORCB3b3VsZCBkby4gQnV0IHRoZSB0cnV0 aCBpcywNCj4gZ2V0dGluZyBhbnl0aGluZyBsaWtlIHRoaXMgaW50byB0aGUgaG9zdCBpcyBnb2lu ZyB0byB0YWtlIGEgZGVjYWRlLCBhbmQNCj4gb25seSBpZiB0aGVyZSBpcyBhIGJ1eW91dC4gSSBm aW5kIHRoZSBjaGFydGVyIHZlcnkgd2lzZSBmcm9tIHRoYXQNCj4gcmVnYXJkOiBubyBuZXcgcHJv dG9jb2wgYWxsb3dlZC4NCj4gDQo+Pg0KPj4+IEluIGEgc2Vuc2UsIGl0J3Mgbm90IHZlcnkgZGlm ZmVyZW50IGZyb20gUlBGLiBJZiB5b3UgZG9uJ3QgaGF2ZSBhDQo+Pj4gcmV0dXJuIHBhdGggdG8g aXQsIGl0IGlzIHN1c3BpY2lvdXMuIE5vdCBicm9rZW4gYmVjYXVzZSB0aGUgbmV4dGhvcA0KPj4+ IHdpbGwgZG8gYWRkcmVzcyByZXNvbHV0aW9uIG9uIHRoZSByZXZlcnNlIHBhdGgsIGJ1dCBzdXNw aWNpb3VzDQo+Pj4gYmVjYXVzZSBiaW5kaW5ncyBhcmUgYW5ub3VuY2VkIGluIGEgZmFpcmx5IHJl ZHVuZGFudCB3YXkgKERBRCAqIG4sDQo+Pj4gTkEsIE5TKjMpDQo+Pg0KPj4gU3RhbmRhcmQgSVB2 NiBEQUQgZG9lcyAxIERBRCBwcm9iZSBhbmQgbm90aGluZyBtb3JlLg0KPj4gVGhlIHByb3Bvc2Fs IEkndmUgc2VlbiBpcyB0byBvbmx5IHJlbHkgb24gdGhhdCBEQUQgcHJvYmUuDQo+Pg0KPiBPbmUg REFEIGlzIHRoZSBkZWZhdWx0LC5jZXJ0YWlubHkgbm90IGEgTVVTVC4gU28gSSBkb24ndCBzZWUg YW55dGhpbmcNCj4gd3JvbmcgaW4gcmVjb21lbW5kaW5nIHRvIHVzZSBhIGhpZ2hlciB2YWx1ZSBp biBhIHNhdmkgc2V0dXAuIEFzIGZhcyBhcw0KPiB1c2luZyBtb3JlIHRoYW4gREFELCB3ZWxsLCBp dCdzIHN0aWxsIG9wZW5lZCwgaXNuJ3QgaXQ/DQo+Pj4gSXQgcmVhbGx5IHRha2VzIHNvbWUgc3Bl Y2lmaWMgY2FzZXMgdG8gbm90IHNlZSBhbnkgYmluZGluZyBwcmlvciB0bw0KPj4+IGZvcndhcmQg YSBob3N0IHRyYWZmaWMuIEFuZCB0aGVuIGl0J3MgYSBtYXR0ZXIgb2YgcG9saWN5OiBZb3VyDQo+ Pj4gZXhhbXBsZSBpcyB0aGUgb25lIG9mIGEgbm9uLXNhdmkgc3dpdGNoICh5b3VyIDgwMi4xRCBi cmlkZ2UpDQo+Pj4gY29ubmVjdGVkIHRvIGEgc2F2aSBzd2l0Y2guIFRoZSBwb2xpY3kgY291bGQg YmUgdG8gZm9yd2FyZCBieSBkZWZhdWx0DQo+Pj4gaW4gdGhpcyBjYXNlLg0KPj4NCj4+IE15IHBy aW1hcnkgZXhhbXBsZSBpcyBTQVZJLzgwMi4xRCBzd2l0Y2hlcyB3aGljaCBsZWF2ZSB0aGUgcG9y dCBpbg0KPj4gYmxvY2tlZCBvciBsZWFybmluZyBzdGF0ZSBmb3IgYSB3aGlsZSB0aGVyZWJ5IGRy b3BwaW5nIHRoZSBEQUQgcHJvYmUuDQo+Pg0KPj4gRm9yIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGlz IGEgbGVnYWN5IHN3aXRjaCBiZXR3ZWVuIHRoZSBob3N0IGFuZCB0aGUNCj4+IFNBVkkgc3dpdGNo IEkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBjb21wbGV0ZWx5IGRpc2FibGUgU0FWSTsgdGhhdA0K Pj4gd291bGQgc2V2ZXJlbHkgbGltaXQgdGhlIHV0aWxpdHkgb2YgU0FWSSAoYW5kIEkgcmVhbGx5 IHdhbnQgdG8gc2VlDQo+PiBTQVZJIGVuYWJsZWQgYnkgZGVmYXVsdCBldmVyeXdoZXJlKSBpbiBj b21tb24gdG9wb2xvZ2llcy4gRm9yIGluc3RhbmNlDQo+PiBjb3Jwb3JhdGUgSVQgb3JnYW5pemF0 aW9ucyB0aGF0IGRlLWZhY3QgZW5jb3VyYWdlIGZvbGtzIHRvIGhhdmUgc21hbGwNCj4+IHVubWFu YWdlZCBzd2l0Y2hlcyBpbiB0aGVpciBvZmZpY2UgYnkgY2hhcmdpbmcgcGVyIEV0aGVybmV0IGRy b3AuDQo+Pg0KPj4gSSB0aGluayB0aGUgV0cgc2hvdWxkIGZpZ3VyZSBvdXQgaG93IHRvIGhhbmRs ZSBzdWNoIGNhc2VzIGluIGEgcm9idXN0DQo+PiBtYW5uZXIuDQo+IEkgYW0gbm90IHJ1bGluZyB0 aGF0IG91dC4gQnV0IGEgbm9uLXNhdmkgc3dpdGNoLCBub3QgZG9pbmcNCj4gYXV0aGVudGljYXRp b24gYXQgbGF5ZXIyLCBjb25uZWN0ZWQgdG8gYSBzYXZpIHN3aXRjaCBpcyB0aGUgaGFyZCBjYXNl LiBJDQo+IHdvdWxkIG5vdCBwcmUtcmVxIHNvbHZpbmcgaXQgdG8gbWFrZSBwcm9ncmVzcyBvbiB0 aGUgb3RoZXIgY2FzZXMuDQo+IEVyaWMNCj4+DQo+PiAgICBFcmlrDQo+Pg0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2F2aSBtYWlsaW5n IGxpc3QNCj4gc2F2aUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhdmkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gc2F2aSBtYWlsaW5nIGxpc3QNCj4gc2F2aUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhdmkNCj4gDQo+IA0KPiANCj4= From elevyabe@cisco.com Wed Aug 5 06:11:23 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB6D3A7174 for ; Wed, 5 Aug 2009 06:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.456 X-Spam-Level: X-Spam-Status: No, score=-7.456 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVGCBmzSeV3n for ; Wed, 5 Aug 2009 06:11:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 299003A7172 for ; Wed, 5 Aug 2009 06:11:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFAIYheUqrR7PD/2dsb2JhbACCJDG5f4gpkGMFg1BIgVE X-IronPort-AV: E=Sophos;i="4.43,328,1246838400"; d="scan'208,217";a="223713475" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 05 Aug 2009 13:11:24 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n75DBPDF010461; Wed, 5 Aug 2009 06:11:25 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n75DA9g0025692; Wed, 5 Aug 2009 13:11:24 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:11:21 +0200 Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Aug 2009 15:11:20 +0200 Message-ID: <4A7984F8.5010107@cisco.com> Date: Wed, 05 Aug 2009 15:11:20 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dong Zhang References: <4A784771.6000600@cisco.com> <200908051021361825410@huaweisymantec.com> In-Reply-To: <200908051021361825410@huaweisymantec.com> Content-Type: multipart/alternative; boundary="------------010307030303010006010907" X-OriginalArrivalTime: 05 Aug 2009 13:11:21.0004 (UTC) FILETIME=[39C37EC0:01CA15CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7926; t=1249477885; x=1250341885; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20Question=20for=20draft-levy-abegnoli-sa vi-plbt-01 |Sender:=20; bh=SHv036VGTr8xwltM2R6T2Pdzbpwx/dZlXF9N97TDB6g=; b=elUhjBzbUGO0Xz20O6/lzZ4Y4x0iE/kgSYihWkld77Uz8GBQR53mtu+HrU +VtI3TXOOzfIENWEzbDCzZWrPavKP9dVBaKNA8MQj1g43BtQOjyVaKob3LWk eB1I88EpS5; Authentication-Results: sj-dkim-3; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SAVI Mailing List , Greg Daley Subject: Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 13:11:23 -0000 This is a multi-part message in MIME format. --------------010307030303010006010907 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Hi Dong, to add up to Greg's response ... Dong Zhang a ¨¦crit: > Hi Eric, > > I have a litte confusion here. > >> Consider the case of a link with a mix of ND (RFC4861] and SeND >> (RFC3971] nodes. Consider node A running ND, node B and node C >> running SeND. >> > Can the mix of ND and SeND in a same link be a common case? I mean > if this happens, how to handle the NA/NS between SeND node and non- > SeND node? > > I tend to think that this is going to be the prevalent case. It is hard to imagine that one will deploy SeND on all nodes from day 1. Current status of SeND is that some vendors have implemented it, and others have not. So to start taking some advantage of it, in any heterogeneous setup, it would sound reasonnable to expect a mix of ND and SeND, and have the SeND nodes more secure that the others. By a matter of fact RFC3971 does describe this situation. I must also add that we are starting to see it in the field. What I was pointing out is that, given how RFC3971 suggest to handle such situation, a "fcfs" switch will break it, and render SeND nodes as insecure as ND nodes. Not a great achievement ... Basically, SeND defines a preference algorithm which in a sense is similar to mine: nodes should prefer the most secure binding, not the first one they see. hence the breakage ... >> The following preflevel values have been identified (from lowest to >> highest): >> o LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2) >> are identical; >> o TRUNK_PORT: the entry was learnt from a trunk port (connected to >> another switch) >> o ACCESS_PORT: the entry was leant from an access port (connected to >> a host) >> o TRUSTED_ACCESS: The entry was learnt from a trusted port >> o TRUSTED_TRUNK: The entry was learnt from a trusted trunk >> o DHCP_ASSIGNED: the entry is assigned by DHCP >> o CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972] >> o CERT_AUTHENTICATED: the entry is authenticated with a certificate >> o STATIC: this is a statically configured entry per [RFC3971]. >> > Then what about ACCESS_PORT+DHCP_ASSIGNED and TRUNK_PORT+CGA_AUTHENTICATED, > which is bigger? > I think there will be some different cases and combinations of the preflevel > values. Is it necessary and possible to list every case, giving particular > illustration? Then it will be much more clear. Perhaps I might miss something. > Given the encoding that I proposed, the sum of *everything* smaller than for instance CGA_AUTHENTICATED cannot be equal or bigger than CGA_AUTHENTICATED. Let me put values to illustrate: LLA_MAC_MATCH = 2**1 = 2 TRUNK_PORT = 2**2 = 4 ACCESS_PORT = 8 TRUSTED_ACCESS = 16 DHCP_ASSIGNED = 32 CGA_AUTHENTICATED = 64 CERT_AUTHENTICATED = 128 STATIC = 256 So ACCESS_PORT+DHCP_ASSIGNED would be 40 'decimal). TRUNK_PORT+CGA_AUTHENTICATED would be 68. The idea is that there is a strict order in this list (I am opened to discuss that order of course). But you can still add up values. So a CGA assigned with DHCP would be prefered over a CGA assigned by SLACC. But a non CGA assigned by DHCP would never be preferred over a CGA. Hope that clarifies the mechanism. Which I think is actually implementaton-firndly, because the comparaison is very straigh forward. Eric > Thank you. > ------------------ > Dong Zhang > 2009-08-05 > > > --------------010307030303010006010907 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit 
Hi Dong,
to add up to Greg's response ...

Dong Zhang a ¨¦crit : 
Hi Eric,

I have a litte confusion here.
  
Consider the case of a link with a mix of ND (RFC4861] and SeND
(RFC3971] nodes.  Consider node A running ND, node B and node C
running SeND. 
    
Can the mix of ND and SeND in a same link be a common case? I mean 
if this happens, how to handle the NA/NS between SeND node and non-
SeND node?  

  
I tend to think that this is going to be the prevalent case. It is hard to imagine that one will deploy SeND on all nodes from day 1.
Current status of SeND is that some vendors have implemented it, and others have not. So to start taking some advantage of it, in any
heterogeneous setup, it would sound reasonnable to expect a mix of ND and SeND, and have the SeND nodes more secure that the others.
By a matter of fact RFC3971 does describe this situation. I must also add that we are starting to see it in the field.
What I was pointing out is that, given how RFC3971 suggest to handle such situation, a "fcfs" switch will break it, and render SeND nodes as
insecure as ND nodes. Not a great achievement ...
Basically, SeND defines a preference algorithm which in a sense is similar to mine: nodes should prefer the most secure binding,
not the first one they see. hence the breakage ... 



  

    
The following preflevel values have been identified (from lowest to
highest):
o  LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2)
  are identical;
o  TRUNK_PORT: the entry was learnt from a trunk port (connected to
  another switch)
o  ACCESS_PORT: the entry was leant from an access port (connected to
  a host)
o  TRUSTED_ACCESS: The entry was learnt from a trusted port
o  TRUSTED_TRUNK: The entry was learnt from a trusted trunk
o  DHCP_ASSIGNED: the entry is assigned by DHCP
o  CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972]
o  CERT_AUTHENTICATED: the entry is authenticated with a certificate
o  STATIC: this is a statically configured entry per [RFC3971].
    

  

  
Then what about ACCESS_PORT+DHCP_ASSIGNED and TRUNK_PORT+CGA_AUTHENTICATED, 
which is bigger?
I think there will be some different cases and combinations of the preflevel 
values. Is it necessary and possible to list every case, giving particular 
illustration? Then it will be much more clear. Perhaps I might miss something.
  




Given the encoding that I proposed, the sum of *everything* smaller than for instance CGA_AUTHENTICATED
cannot be equal or bigger than CGA_AUTHENTICATED. Let me put values to illustrate:
LLA_MAC_MATCH = 2**1 = 2
TRUNK_PORT = 2**2 = 4
ACCESS_PORT = 8
TRUSTED_ACCESS = 16
DHCP_ASSIGNED = 32
CGA_AUTHENTICATED = 64
CERT_AUTHENTICATED = 128
STATIC = 256

So ACCESS_PORT+DHCP_ASSIGNED would be 40 'decimal).
TRUNK_PORT+CGA_AUTHENTICATED would be 68.

The idea is that there is a strict order in this list (I am opened to discuss that order of course). But you can still
add up values. So a CGA assigned with DHCP would be prefered over a CGA assigned by SLACC. But a non CGA assigned by DHCP would
never be preferred over a CGA.
Hope that clarifies the mechanism. Which I think is actually implementaton-firndly, because the comparaison is very straigh forward.
Eric






  
Thank you.
------------------				 
Dong Zhang                        
2009-08-05


  








--------------010307030303010006010907--

From elevyabe@cisco.com  Wed Aug  5 06:15:09 2009
Return-Path: 
X-Original-To: savi@core3.amsl.com
Delivered-To: savi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EE53A71BC for ; Wed,  5 Aug 2009 06:15:09 -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.250,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkKjB5Yr4KtY for ; Wed,  5 Aug 2009 06:15:08 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D7EFE3A71D3 for ; Wed,  5 Aug 2009 06:14:41 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkcAAO8ieUqQ/uCKe2dsb2JhbACCJTCXYwEBFiQGoVaIKZBgBYIxgWeBUQ
X-IronPort-AV: E=Sophos;i="4.43,328,1246838400"; d="scan'208,217";a="46506204"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Aug 2009 13:14:43 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n75DEhAY023985;  Wed, 5 Aug 2009 15:14:43 +0200
Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n75DEhiL021696; Wed, 5 Aug 2009 13:14:43 GMT
Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 5 Aug 2009 15:14:43 +0200
Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 5 Aug 2009 15:14:42 +0200
Message-ID: <4A7985C2.4040003@cisco.com>
Date: Wed, 05 Aug 2009 15:14:42 +0200
From: Eric Levy-Abegnoli 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Greg Daley 
References: <4A784771.6000600@cisco.com> <200908051021361825410@huaweisymantec.com> <6983BF97BFC24D4EA551F14071232918011CEF02@melmail.netstarnetworks.com>
In-Reply-To: <6983BF97BFC24D4EA551F14071232918011CEF02@melmail.netstarnetworks.com>
Content-Type: multipart/alternative; boundary="------------010404000606070905030702"
X-OriginalArrivalTime: 05 Aug 2009 13:14:42.0512 (UTC) FILETIME=[B1DF2D00:01CA15CE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7876; t=1249478083; x=1250342083; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20Question=20for=20draft-levy-ab egnoli-savi-plbt-01 |Sender:=20; bh=Eeat7bm7PMp6RsK91s4Om6YyXbaRgjC0LLDp0E3gHpc=; b=DEVzrGMOci+cGBaYa5KzdTAIHvpFNfruE1Bwvg5ZL3tPRCdaG4VjyARDg7 SI+s409q+Unj58OKObleGsvw3emVL4/aMdMsmDG4IordmuWBzkFnfVhyqXt/ 4hTpkE+pTS;
Authentication-Results: ams-dkim-1; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Cc: SAVI Mailing List 
Subject: Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the SAVI WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Aug 2009 13:15:09 -0000

This is a multi-part message in MIME format.
--------------010404000606070905030702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Greg,

Greg Daley a écrit :
> Hi Dong, 
>
>   
>> Can the mix of ND and SeND in a same link be a common case? I mean 
>> if this happens, how to handle the NA/NS between SeND node and non-
>> SeND node?  
>>     
>
> SEND/non-SEND interoperation is dealt with extensively in RFC3971.
>
> It does make sense to have a mix of nodes on the LAN, and this allows
> incremental security deployment.
>
>   
>>> The following preflevel values have been identified (from lowest to
>>> highest):
>>> o  LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2)
>>>   are identical;
>>> o  TRUNK_PORT: the entry was learnt from a trunk port (connected to
>>>   another switch)
>>> o  ACCESS_PORT: the entry was leant from an access port (connected to
>>>   a host)
>>> o  TRUSTED_ACCESS: The entry was learnt from a trusted port
>>> o  TRUSTED_TRUNK: The entry was learnt from a trusted trunk
>>> o  DHCP_ASSIGNED: the entry is assigned by DHCP
>>> o  CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972]
>>> o  CERT_AUTHENTICATED: the entry is authenticated with a certificate
>>> o  STATIC: this is a statically configured entry per [RFC3971].
>>>       
>
>   
>> Then what about ACCESS_PORT+DHCP_ASSIGNED and
>>     
> TRUNK_PORT+CGA_AUTHENTICATED,  which is bigger?
>   
>> I think there will be some different cases and combinations  of the
>>     
> preflevel 
>   
>> values. Is it necessary and possible to list every case,  giving
>>     
> particular 
>   
>> illustration? Then it will be much more clear. Perhaps I  might miss
>>     
> something.
>
>
> Since the bindings identify the level of authority attained about the 
> address mapping, only the highest of these should be considered.
>
> The presence of CGA_AUTHENTICATED means the higher level of
> certification
> which has been attained by the binding.   This would supercede a
> previous
> (or contemporary) binding of TRUNK_PORT.  Therefore the binding state
> would
> be CGA_AUTHENTICATED.
>
> Similarly, with ACCESS_PORT+DHCP_ASSIGNED, the DHCP assignment is a
> control process which can be authenticated and is specified by a server.
> This has more authority than the ACCESS_PORT binding.  Therefore this
> binding's state is DHCP_ASSIGNED.
>
> Comparison of these bindings therefore becomes simpler: DHCP_ASSIGNED vs
> CGA_AUTHENTICATED
>
> Perhaps some clarifying words could be put into the draft?
>
>   
I guess so. If this was not crystal clear in the current writing, it 
means I need to clarify.  You got it allright though,
so it must not have been too bad :)
Maybe I'll add an example with some values ...
Thanks
eric
> Please note that an address binding can be both CGA Authenticated and
> DHCPv6 assigned, since
> a node can propose its address in DHCPv6 based on known address
> prefixes.  In this case,
> the fact that the device can perform SEND CGA Auth on the address lends
> more authority to the
> binding (giving CGA_AUTHENTICATED) state.
>
>
> Sincerely,
>
> Greg Daley
> Security Consultant
> NetStar Australia Pty Ltd
>
> E-mail: gdaley@netstarnetworks.com
> Mobile: +61 401 772 770
> Direct: +61 3 8532 4042
> Fax:    +61 3 8532 4032 
>
>   


--------------010404000606070905030702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Hi Greg,



Greg Daley a écrit :


  
Hi Dong, 

  

  

    
Can the mix of ND and SeND in a same link be a common case? I mean 
if this happens, how to handle the NA/NS between SeND node and non-
SeND node?  
    

  

  

SEND/non-SEND interoperation is dealt with extensively in RFC3971.

It does make sense to have a mix of nodes on the LAN, and this allows
incremental security deployment.

  

  

    

      
The following preflevel values have been identified (from lowest to
highest):
o  LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2)
  are identical;
o  TRUNK_PORT: the entry was learnt from a trunk port (connected to
  another switch)
o  ACCESS_PORT: the entry was leant from an access port (connected to
  a host)
o  TRUSTED_ACCESS: The entry was learnt from a trusted port
o  TRUSTED_TRUNK: The entry was learnt from a trusted trunk
o  DHCP_ASSIGNED: the entry is assigned by DHCP
o  CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972]
o  CERT_AUTHENTICATED: the entry is authenticated with a certificate
o  STATIC: this is a statically configured entry per [RFC3971].
      

    

  

  

  

  

    
Then what about ACCESS_PORT+DHCP_ASSIGNED and
    

  

  
TRUNK_PORT+CGA_AUTHENTICATED,  which is bigger?
  

  

    
I think there will be some different cases and combinations  of the
    

  

  
preflevel 
  

  

    
values. Is it necessary and possible to list every case,  giving
    

  

  
particular 
  

  

    
illustration? Then it will be much more clear. Perhaps I  might miss
    

  

  
something.


Since the bindings identify the level of authority attained about the 
address mapping, only the highest of these should be considered.

The presence of CGA_AUTHENTICATED means the higher level of
certification
which has been attained by the binding.   This would supercede a
previous
(or contemporary) binding of TRUNK_PORT.  Therefore the binding state
would
be CGA_AUTHENTICATED.

Similarly, with ACCESS_PORT+DHCP_ASSIGNED, the DHCP assignment is a
control process which can be authenticated and is specified by a server.
This has more authority than the ACCESS_PORT binding.  Therefore this
binding's state is DHCP_ASSIGNED.

Comparison of these bindings therefore becomes simpler: DHCP_ASSIGNED vs
CGA_AUTHENTICATED

Perhaps some clarifying words could be put into the draft?

  



I guess so. If this was not crystal clear in the current writing, it
means I need to clarify.  You got it allright though, 

so it must not have been too bad :)

Maybe I'll add an example with some values ...

Thanks

eric



  
Please note that an address binding can be both CGA Authenticated and
DHCPv6 assigned, since
a node can propose its address in DHCPv6 based on known address
prefixes.  In this case,
the fact that the device can perform SEND CGA Auth on the address lends
more authority to the
binding (giving CGA_AUTHENTICATED) state.


Sincerely,

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: gdaley@netstarnetworks.com
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032 

  








--------------010404000606070905030702--

From zhangdong_rh@huaweisymantec.com  Wed Aug  5 19:05:09 2009
Return-Path: 
X-Original-To: savi@core3.amsl.com
Delivered-To: savi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DC53A67DD for ; Wed,  5 Aug 2009 19:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.65
X-Spam-Level: **
X-Spam-Status: No, score=2.65 tagged_above=-999 required=5 tests=[AWL=-1.659,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY7sGQK9Q+EC for ; Wed,  5 Aug 2009 19:05:07 -0700 (PDT)
Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 08F913A6C9E for ; Wed,  5 Aug 2009 19:04:43 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_BoD81j7cFHOTvMKMgiFqpg)"
Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KNX00DJ4N3NDN10@hstga01-in.huaweisymantec.com> for savi@ietf.org; Thu, 06 Aug 2009 10:04:35 +0800 (CST)
Received: from z90001956 ([10.27.154.76]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KNX004WRN3MLC00@hstml01-in.huaweisymantec.com> for savi@ietf.org; Thu, 06 Aug 2009 10:04:35 +0800 (CST)
Date: Thu, 06 Aug 2009 10:04:32 +0800
From: Dong Zhang 
To: Eric Levy-Abegnoli , Greg Daley 
References: <4A784771.6000600@cisco.com> <200908051021361825410@huaweisymantec.com> <6983BF97BFC24D4EA551F14071232918011CEF02@melmail.netstarnetworks.com> <4A7985C2.4040003@cisco.com>
Message-id: <200908061004324896481@huaweisymantec.com>
X-Mailer: Foxmail 6, 10, 201, 20 [cn]
Cc: SAVI Mailing List 
Subject: Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the SAVI WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Aug 2009 02:05:09 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_BoD81j7cFHOTvMKMgiFqpg)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

SGkgRXJpYywNCg0KUGxlYXNlIGNoZWNrIGlubGluZS4NCg0KMjAwOS0wOC0wNiANCg0KDQoNCkRv
bmcgWmhhbmcNCg0KDQoNCreivP7Iy6O6IEVyaWMgTGV2eS1BYmVnbm9saSANCreiy83Ksbzko7og
MjAwOS0wOC0wNSAgMjE6MTQ6NTAgDQrK1bz+yMujuiBHcmVnIERhbGV5IA0Ks63LzaO6IERvbmcg
Wmhhbmc7IFNBVkkgTWFpbGluZyBMaXN0IA0K1vfM4qO6IFJlOiBbc2F2aV0gUXVlc3Rpb24gZm9y
IGRyYWZ0LWxldnktYWJlZ25vbGktc2F2aS1wbGJ0LTAxIA0KIA0KSGkgR3JlZywNCg0KR3JlZyBE
YWxleSBhIKimY3JpdCA6IA0KSGkgRG9uZywgDQoNCiAgDQpDYW4gdGhlIG1peCBvZiBORCBhbmQg
U2VORCBpbiBhIHNhbWUgbGluayBiZSBhIGNvbW1vbiBjYXNlPyBJIG1lYW4gDQppZiB0aGlzIGhh
cHBlbnMsIGhvdyB0byBoYW5kbGUgdGhlIE5BL05TIGJldHdlZW4gU2VORCBub2RlIGFuZCBub24t
DQpTZU5EIG5vZGU/ICANCiAgICANCg0KU0VORC9ub24tU0VORCBpbnRlcm9wZXJhdGlvbiBpcyBk
ZWFsdCB3aXRoIGV4dGVuc2l2ZWx5IGluIFJGQzM5NzEuDQoNCkl0IGRvZXMgbWFrZSBzZW5zZSB0
byBoYXZlIGEgbWl4IG9mIG5vZGVzIG9uIHRoZSBMQU4sIGFuZCB0aGlzIGFsbG93cw0KaW5jcmVt
ZW50YWwgc2VjdXJpdHkgZGVwbG95bWVudC4NCg0KICANClRoZSBmb2xsb3dpbmcgcHJlZmxldmVs
IHZhbHVlcyBoYXZlIGJlZW4gaWRlbnRpZmllZCAoZnJvbSBsb3dlc3QgdG8NCmhpZ2hlc3QpOg0K
byAgTExBX01BQ19NQVRDSDogTExBIChmb3VuZCBpbiBORFAgb3B0aW9uKSBhbmQgTUFDIChmb3Vu
ZCBhdCBsYXllcjIpDQogIGFyZSBpZGVudGljYWw7DQpvICBUUlVOS19QT1JUOiB0aGUgZW50cnkg
d2FzIGxlYXJudCBmcm9tIGEgdHJ1bmsgcG9ydCAoY29ubmVjdGVkIHRvDQogIGFub3RoZXIgc3dp
dGNoKQ0KbyAgQUNDRVNTX1BPUlQ6IHRoZSBlbnRyeSB3YXMgbGVhbnQgZnJvbSBhbiBhY2Nlc3Mg
cG9ydCAoY29ubmVjdGVkIHRvDQogIGEgaG9zdCkNCm8gIFRSVVNURURfQUNDRVNTOiBUaGUgZW50
cnkgd2FzIGxlYXJudCBmcm9tIGEgdHJ1c3RlZCBwb3J0DQpvICBUUlVTVEVEX1RSVU5LOiBUaGUg
ZW50cnkgd2FzIGxlYXJudCBmcm9tIGEgdHJ1c3RlZCB0cnVuaw0KbyAgREhDUF9BU1NJR05FRDog
dGhlIGVudHJ5IGlzIGFzc2lnbmVkIGJ5IERIQ1ANCm8gIENHQV9BVVRIRU5USUNBVEVEOiBUaGUg
ZW50cnkgaXMgQ0dBIGF1dGhlbnRpY2F0ZWQsIHBlciBbUkZDMzk3Ml0NCm8gIENFUlRfQVVUSEVO
VElDQVRFRDogdGhlIGVudHJ5IGlzIGF1dGhlbnRpY2F0ZWQgd2l0aCBhIGNlcnRpZmljYXRlDQpv
ICBTVEFUSUM6IHRoaXMgaXMgYSBzdGF0aWNhbGx5IGNvbmZpZ3VyZWQgZW50cnkgcGVyIFtSRkMz
OTcxXS4NCiAgICAgIA0KDQogIA0KVGhlbiB3aGF0IGFib3V0IEFDQ0VTU19QT1JUK0RIQ1BfQVNT
SUdORUQgYW5kDQogICAgDQpUUlVOS19QT1JUK0NHQV9BVVRIRU5USUNBVEVELCAgd2hpY2ggaXMg
YmlnZ2VyPw0KICANCkkgdGhpbmsgdGhlcmUgd2lsbCBiZSBzb21lIGRpZmZlcmVudCBjYXNlcyBh
bmQgY29tYmluYXRpb25zICBvZiB0aGUNCiAgICANCnByZWZsZXZlbCANCiAgDQp2YWx1ZXMuIElz
IGl0IG5lY2Vzc2FyeSBhbmQgcG9zc2libGUgdG8gbGlzdCBldmVyeSBjYXNlLCAgZ2l2aW5nDQog
ICAgDQpwYXJ0aWN1bGFyIA0KICANCmlsbHVzdHJhdGlvbj8gVGhlbiBpdCB3aWxsIGJlIG11Y2gg
bW9yZSBjbGVhci4gUGVyaGFwcyBJICBtaWdodCBtaXNzDQogICAgDQpzb21ldGhpbmcuDQoNCg0K
U2luY2UgdGhlIGJpbmRpbmdzIGlkZW50aWZ5IHRoZSBsZXZlbCBvZiBhdXRob3JpdHkgYXR0YWlu
ZWQgYWJvdXQgdGhlIA0KYWRkcmVzcyBtYXBwaW5nLCBvbmx5IHRoZSBoaWdoZXN0IG9mIHRoZXNl
IHNob3VsZCBiZSBjb25zaWRlcmVkLg0KDQpUaGUgcHJlc2VuY2Ugb2YgQ0dBX0FVVEhFTlRJQ0FU
RUQgbWVhbnMgdGhlIGhpZ2hlciBsZXZlbCBvZg0KY2VydGlmaWNhdGlvbg0Kd2hpY2ggaGFzIGJl
ZW4gYXR0YWluZWQgYnkgdGhlIGJpbmRpbmcuICAgVGhpcyB3b3VsZCBzdXBlcmNlZGUgYQ0KcHJl
dmlvdXMNCihvciBjb250ZW1wb3JhcnkpIGJpbmRpbmcgb2YgVFJVTktfUE9SVC4gIFRoZXJlZm9y
ZSB0aGUgYmluZGluZyBzdGF0ZQ0Kd291bGQNCmJlIENHQV9BVVRIRU5USUNBVEVELg0KDQpTaW1p
bGFybHksIHdpdGggQUNDRVNTX1BPUlQrREhDUF9BU1NJR05FRCwgdGhlIERIQ1AgYXNzaWdubWVu
dCBpcyBhDQpjb250cm9sIHByb2Nlc3Mgd2hpY2ggY2FuIGJlIGF1dGhlbnRpY2F0ZWQgYW5kIGlz
IHNwZWNpZmllZCBieSBhIHNlcnZlci4NClRoaXMgaGFzIG1vcmUgYXV0aG9yaXR5IHRoYW4gdGhl
IEFDQ0VTU19QT1JUIGJpbmRpbmcuICBUaGVyZWZvcmUgdGhpcw0KYmluZGluZydzIHN0YXRlIGlz
IERIQ1BfQVNTSUdORUQuDQoNCkNvbXBhcmlzb24gb2YgdGhlc2UgYmluZGluZ3MgdGhlcmVmb3Jl
IGJlY29tZXMgc2ltcGxlcjogREhDUF9BU1NJR05FRCB2cw0KQ0dBX0FVVEhFTlRJQ0FURUQNCg0K
UGVyaGFwcyBzb21lIGNsYXJpZnlpbmcgd29yZHMgY291bGQgYmUgcHV0IGludG8gdGhlIGRyYWZ0
Pw0KDQogIA0KSSBndWVzcyBzby4gSWYgdGhpcyB3YXMgbm90IGNyeXN0YWwgY2xlYXIgaW4gdGhl
IGN1cnJlbnQgd3JpdGluZywgaXQgbWVhbnMgSSBuZWVkIHRvIGNsYXJpZnkuICBZb3UgZ290IGl0
IGFsbHJpZ2h0IHRob3VnaCwgDQpzbyBpdCBtdXN0IG5vdCBoYXZlIGJlZW4gdG9vIGJhZCA6KQ0K
TWF5YmUgSSdsbCBhZGQgYW4gZXhhbXBsZSB3aXRoIHNvbWUgdmFsdWVzIC4uLg0KVGhhbmtzDQpl
cmljDQpbRG9uZ10gQnV0IEl0IHNlZW1zIHRoZXJlIGlzIHNvbWV0aGluZyBkaWZmZXJlbnQgIGJl
dHdlZW4gR3JlZydzIHVuZGVyc3RhbmRpbmcgYW5kIHlvdXIgZXhwbGFuYXRpb24uIFNvIGFncmVl
IHRvIGFkZCANCnNvbWUgY2xhcmlmaWNhdGlvbiBhcyBteSBsYXN0IG1haWwgc2FpZC4NCg0KW0Rv
bmddIEluIGFkZGl0aW9uLCBJJ20gd29ycmllZCBhYm91dCBhIHBvc3NpYmxlIHNlY3VyaXR5IHBy
b2JsZW0uDQoqKioqKioqKioqKioqDQpUaGUgZHJhZnQgc2F5czoNCiAgIFRoZXJlZm9yZSwgYSBk
YXRhIHBhY2tldCBzaG91bGQgbm90IGJlIHVzZWQgdG8gY29tcGxldGUgdGhlDQogICBiaW5kaW5n
IGVudHJ5LCBidXQgb25seSBhcyBhIGhpbnQgdGhhdCBpdCBzaG91bGQgc2VlayBmb3IgY29tcGxl
dGlvbi4NCiAgIFVwb24gcmVjZWl2aW5nIGEgZGF0YSBwYWNrZXQgY2FycnlpbmcgYSBzb3VyY2Ug
YWRkcmVzcyBub3Qgc2Vlbg0KICAgYmVmb3JlLCB0aGUgc3dpdGNoIHNob3VsZCBpc3N1ZSBhIERB
RCBwYWNrZXQgb24gdGhlIGxpbmsgKGFsbCBwb3J0cw0KICAgb2YgdGhlIHZsYW4pLCBpbmNsdWRp
bmcgdGhlIG9uZSBmcm9tIHdoaWNoIHRoZSBkYXRhIHBhY2tldCB3YXMNCiAgIHJlY2VpdmVkLiAg
VGhlIGFkZHJlc3Mgb3duZXIgaXMgZXhwZWN0ZWQgdG8gcmVzcG9uZCB3aXRoIGFuIE5BLA0KICAg
Y2FycnlpbmcgQ0dBIGNyZWRlbnRpYWxzIGlmIGFueS4gIFVwb24gcmVjZWl2aW5nIHRoaXMgcmVz
cG9uc2UsIHRoZQ0KICAgc3dpdGNoIGNhbiBjb21wbGV0ZSB0aGUgYmluZGluZyBlbnRyeSBhbmQg
c3RhcnQgZm9yd2FyZGluZyB0cmFmZmljDQogICBmcm9tIHRoZSBzb3VyY2UuDQogICAuLi4NCiAg
IEZvciBpbnN0YW5jZSwgdXBvbiByZWNlaXZpbmcgYSBkYXRhIHBhY2tldCwgdGhlDQogICBzd2l0
Y2ggd2lsbCBpc3N1ZSBhIERBRCBOUyBhbmQgd2FpdCBmb3IgYW4gTkEuICBCZWZvcmUgcmVjZWl2
aW5nIHRoZQ0KICAgTkEsIHRoZSBlbnRyeSBpcyBJTUNPTVBMRVRFLiAgVGhlbiBpdCBtb3ZlcyB0
byBSRUFDSEFCTEUuICBUaGVuIHRvDQogICBTVEFMRSB1bmxlc3MgdGhlIGJpbmRpbmcgaXMgY29u
ZmlybWVkIGJ5IG1vcmUgTkRQIHRyYWZmaWMuDQoqKioqKioqKioqKioNClRoaW5raW5nIGFib3V0
IGFuIGF0dGFja2VyIHNlbmRzIGRhdGEgcGFja2V0cyB3aXRoIGRpZmZlcmVudCBmb3JnZWQgc291
cmNlIGFkZHJlc3NlcyBpbmNlc3NhbnRseS4gVGhlbiB0aGVzZSBkYXRhIHBhY2tldHMgbGVhZCAN
CnRoZSBzYXZpIHN3aXRjaCB0byBzZW5kIERBRCBhbmQgd2FpdCBmb3IgTkEgcmVzcG9uc2UuIElu
IHRoaXMgY2FzZSwgYSBEb1MgYXR0YWNrIGFyaXNlLiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv
biBzaG91bGQgYmUgYWRkZWQuDQpBbmQgdGhlIGVudHJ5IGJpbmRpbmdzIHdpdGggSU1DT01QTEVU
RSBzdGF0ZSBjb3N0IHRoZSBtZW1vcnkgd2hpbGUgd2FpdGluZyBmb3IgdGhlIHJlc3BvbnNlLiBN
YXliZSBhIHN0YXRlIG1hY2hpbmUgaXMgbmVlZCBmb3IgDQp0aGUgc3RhdGUgdHJhbnNpdGlvbi4g
VGhlIGJlaGF2aW9yIG9mIHNhdmkgc3dpdGNoIG1pZ2h0IGJlIHNvbWV0aGluZyBsaWtlIHRoaXM6
DQpUcmlnZ2VyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEFjdGlvbg0KUmVjZWl2ZSBhIGRhdGEgcGFja2V0ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZSBhIElNQ09NUExFVEUgZW50cnks
IHNlbmQgREFEIE5TDQpJZiByZWNlaXZlIGEgTkEgd2l0aGluIHgodGhlIGV4YWN0IHNlY29uZHMs
IGUuZy4gM3MgKSAgIElNQ09NUExFVEUgbW92ZXMgdG8gUkVBQ0hBQkxFDQpJZiByZWNlaXZlIG5v
IE5BIHdpdGhpbiB4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbGVt
aW5hdGUgdGhlIElNQ09NUExFVEUgZW50cnkNCi4uLiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uDQoNClRoYW5r
IHlvdS4NCkRvbmcNClBsZWFzZSBub3RlIHRoYXQgYW4gYWRkcmVzcyBiaW5kaW5nIGNhbiBiZSBi
b3RoIENHQSBBdXRoZW50aWNhdGVkIGFuZA0KREhDUHY2IGFzc2lnbmVkLCBzaW5jZQ0KYSBub2Rl
IGNhbiBwcm9wb3NlIGl0cyBhZGRyZXNzIGluIERIQ1B2NiBiYXNlZCBvbiBrbm93biBhZGRyZXNz
DQpwcmVmaXhlcy4gIEluIHRoaXMgY2FzZSwNCnRoZSBmYWN0IHRoYXQgdGhlIGRldmljZSBjYW4g
cGVyZm9ybSBTRU5EIENHQSBBdXRoIG9uIHRoZSBhZGRyZXNzIGxlbmRzDQptb3JlIGF1dGhvcml0
eSB0byB0aGUNCmJpbmRpbmcgKGdpdmluZyBDR0FfQVVUSEVOVElDQVRFRCkgc3RhdGUuDQoNCg0K
U2luY2VyZWx5LA0KDQpHcmVnIERhbGV5DQpTZWN1cml0eSBDb25zdWx0YW50DQpOZXRTdGFyIEF1
c3RyYWxpYSBQdHkgTHRkDQoNCkUtbWFpbDogZ2RhbGV5QG5ldHN0YXJuZXR3b3Jrcy5jb20NCk1v
YmlsZTogKzYxIDQwMSA3NzIgNzcwDQpEaXJlY3Q6ICs2MSAzIDg1MzIgNDA0Mg0KRmF4OiAgICAr
NjEgMyA4NTMyIDQwMzIgDQoNCiAgDQo=

--Boundary_(ID_BoD81j7cFHOTvMKMgiFqpg)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yOTAwLjM1NjIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt
ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9
DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7
c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw
dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog
aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg
Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM
SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6
IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t
YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ
Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw
cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K
fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N
ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl
cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1
bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7
IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O
VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg
Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5
cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN
Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO
LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN
CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U
T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg
c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9O
VCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDAwMCBzaXplPTI+SGkgRXJpYyw8L0ZPTlQ+PC9ESVY+
DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O
VCBjb2xvcj0jMDAwMDAwPlBsZWFzZSBjaGVjayBpbmxpbmUuPC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW
Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAwOS0wOC0w
NiA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+
DQo8SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0y
Pg0KPC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+
PFNQQU4+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PFNUUk9ORz5Eb25nIFpoYW5n
PC9TVFJPTkc+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+DQo8RElWPjxG
T05UIGZhY2U9VmVyZGFuYT48Rk9OVCANCmNvbG9yPSMwMDAwMDA+PC9GT05UPjwvRk9OVD48L0RJ
Vj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPVZlcmRhbmEgDQpjb2xvcj0jMDAwMDgw
IHNpemU9Mj4NCjxIUj4NCjwvRk9OVD48L0RJVj48L0RJVj48L0RJVj4NCjxESVY+PEZPTlQgZmFj
ZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPreivP7Iy6O6PC9TVFJPTkc+IEVyaWMgTGV2eS1BYmVn
bm9saSANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RS
T05HPreiy83Ksbzko7o8L1NUUk9ORz4gMjAwOS0wOC0wNSZuYnNwOyAyMToxNDo1MCANCjwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6
PC9TVFJPTkc+IEdyZWcgRGFsZXkgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRh
bmEgc2l6ZT0yPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IERvbmcgWmhhbmc7IFNBVkkgTWFpbGlu
ZyANCkxpc3QgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxT
VFJPTkc+1vfM4qO6PC9TVFJPTkc+IFJlOiBbc2F2aV0gUXVlc3Rpb24gZm9yIA0KZHJhZnQtbGV2
eS1hYmVnbm9saS1zYXZpLXBsYnQtMDEgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl
cmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl
PTI+SGkgR3JlZyw8QlI+PEJSPkdyZWcgRGFsZXkgYSCopmNyaXQmbmJzcDs6IDwvRElWPg0KPEJM
T0NLUVVPVEUgDQpjaXRlPW1pZDo2OTgzQkY5N0JGQzI0RDRFQTU1MUYxNDA3MTIzMjkxODAxMUNF
RjAyQG1lbG1haWwubmV0c3Rhcm5ldHdvcmtzLmNvbSANCnR5cGU9ImNpdGUiPjxQUkUgd3JhcD0i
Ij5IaSBEb25nLCANCg0KICA8L1BSRT4NCiAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3
cmFwPSIiPkNhbiB0aGUgbWl4IG9mIE5EIGFuZCBTZU5EIGluIGEgc2FtZSBsaW5rIGJlIGEgY29t
bW9uIGNhc2U/IEkgbWVhbiANCmlmIHRoaXMgaGFwcGVucywgaG93IHRvIGhhbmRsZSB0aGUgTkEv
TlMgYmV0d2VlbiBTZU5EIG5vZGUgYW5kIG5vbi0NClNlTkQgbm9kZT8gIA0KICAgIDwvUFJFPjwv
QkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+PCEtLS0tPg0KU0VORC9ub24tU0VORCBpbnRlcm9wZXJh
dGlvbiBpcyBkZWFsdCB3aXRoIGV4dGVuc2l2ZWx5IGluIFJGQzM5NzEuDQoNCkl0IGRvZXMgbWFr
ZSBzZW5zZSB0byBoYXZlIGEgbWl4IG9mIG5vZGVzIG9uIHRoZSBMQU4sIGFuZCB0aGlzIGFsbG93
cw0KaW5jcmVtZW50YWwgc2VjdXJpdHkgZGVwbG95bWVudC4NCg0KICA8L1BSRT4NCiAgPEJMT0NL
UVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3cmFw
PSIiPlRoZSBmb2xsb3dpbmcgcHJlZmxldmVsIHZhbHVlcyBoYXZlIGJlZW4gaWRlbnRpZmllZCAo
ZnJvbSBsb3dlc3QgdG8NCmhpZ2hlc3QpOg0KbyAgTExBX01BQ19NQVRDSDogTExBIChmb3VuZCBp
biBORFAgb3B0aW9uKSBhbmQgTUFDIChmb3VuZCBhdCBsYXllcjIpDQogIGFyZSBpZGVudGljYWw7
DQpvICBUUlVOS19QT1JUOiB0aGUgZW50cnkgd2FzIGxlYXJudCBmcm9tIGEgdHJ1bmsgcG9ydCAo
Y29ubmVjdGVkIHRvDQogIGFub3RoZXIgc3dpdGNoKQ0KbyAgQUNDRVNTX1BPUlQ6IHRoZSBlbnRy
eSB3YXMgbGVhbnQgZnJvbSBhbiBhY2Nlc3MgcG9ydCAoY29ubmVjdGVkIHRvDQogIGEgaG9zdCkN
Cm8gIFRSVVNURURfQUNDRVNTOiBUaGUgZW50cnkgd2FzIGxlYXJudCBmcm9tIGEgdHJ1c3RlZCBw
b3J0DQpvICBUUlVTVEVEX1RSVU5LOiBUaGUgZW50cnkgd2FzIGxlYXJudCBmcm9tIGEgdHJ1c3Rl
ZCB0cnVuaw0KbyAgREhDUF9BU1NJR05FRDogdGhlIGVudHJ5IGlzIGFzc2lnbmVkIGJ5IERIQ1AN
Cm8gIENHQV9BVVRIRU5USUNBVEVEOiBUaGUgZW50cnkgaXMgQ0dBIGF1dGhlbnRpY2F0ZWQsIHBl
ciBbUkZDMzk3Ml0NCm8gIENFUlRfQVVUSEVOVElDQVRFRDogdGhlIGVudHJ5IGlzIGF1dGhlbnRp
Y2F0ZWQgd2l0aCBhIGNlcnRpZmljYXRlDQpvICBTVEFUSUM6IHRoaXMgaXMgYSBzdGF0aWNhbGx5
IGNvbmZpZ3VyZWQgZW50cnkgcGVyIFtSRkMzOTcxXS4NCiAgICAgIDwvUFJFPjwvQkxPQ0tRVU9U
RT48L0JMT0NLUVVPVEU+PFBSRSB3cmFwPSIiPjwhLS0tLT4NCiAgPC9QUkU+DQogIDxCTE9DS1FV
T1RFIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj5UaGVuIHdoYXQgYWJvdXQgQUNDRVNTX1BPUlQr
REhDUF9BU1NJR05FRCBhbmQNCiAgICA8L1BSRT48L0JMT0NLUVVPVEU+PFBSRSB3cmFwPSIiPjwh
LS0tLT5UUlVOS19QT1JUK0NHQV9BVVRIRU5USUNBVEVELCAgd2hpY2ggaXMgYmlnZ2VyPw0KICA8
L1BSRT4NCiAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPkkgdGhpbmsgdGhl
cmUgd2lsbCBiZSBzb21lIGRpZmZlcmVudCBjYXNlcyBhbmQgY29tYmluYXRpb25zICBvZiB0aGUN
CiAgICA8L1BSRT48L0JMT0NLUVVPVEU+PFBSRSB3cmFwPSIiPjwhLS0tLT5wcmVmbGV2ZWwgDQog
IDwvUFJFPg0KICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+dmFsdWVzLiBJ
cyBpdCBuZWNlc3NhcnkgYW5kIHBvc3NpYmxlIHRvIGxpc3QgZXZlcnkgY2FzZSwgIGdpdmluZw0K
ICAgIDwvUFJFPjwvQkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+PCEtLS0tPnBhcnRpY3VsYXIgDQog
IDwvUFJFPg0KICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+aWxsdXN0cmF0
aW9uPyBUaGVuIGl0IHdpbGwgYmUgbXVjaCBtb3JlIGNsZWFyLiBQZXJoYXBzIEkgIG1pZ2h0IG1p
c3MNCiAgICA8L1BSRT48L0JMT0NLUVVPVEU+PFBSRSB3cmFwPSIiPjwhLS0tLT5zb21ldGhpbmcu
DQoNCg0KU2luY2UgdGhlIGJpbmRpbmdzIGlkZW50aWZ5IHRoZSBsZXZlbCBvZiBhdXRob3JpdHkg
YXR0YWluZWQgYWJvdXQgdGhlIA0KYWRkcmVzcyBtYXBwaW5nLCBvbmx5IHRoZSBoaWdoZXN0IG9m
IHRoZXNlIHNob3VsZCBiZSBjb25zaWRlcmVkLg0KDQpUaGUgcHJlc2VuY2Ugb2YgQ0dBX0FVVEhF
TlRJQ0FURUQgbWVhbnMgdGhlIGhpZ2hlciBsZXZlbCBvZg0KY2VydGlmaWNhdGlvbg0Kd2hpY2gg
aGFzIGJlZW4gYXR0YWluZWQgYnkgdGhlIGJpbmRpbmcuICAgVGhpcyB3b3VsZCBzdXBlcmNlZGUg
YQ0KcHJldmlvdXMNCihvciBjb250ZW1wb3JhcnkpIGJpbmRpbmcgb2YgVFJVTktfUE9SVC4gIFRo
ZXJlZm9yZSB0aGUgYmluZGluZyBzdGF0ZQ0Kd291bGQNCmJlIENHQV9BVVRIRU5USUNBVEVELg0K
DQpTaW1pbGFybHksIHdpdGggQUNDRVNTX1BPUlQrREhDUF9BU1NJR05FRCwgdGhlIERIQ1AgYXNz
aWdubWVudCBpcyBhDQpjb250cm9sIHByb2Nlc3Mgd2hpY2ggY2FuIGJlIGF1dGhlbnRpY2F0ZWQg
YW5kIGlzIHNwZWNpZmllZCBieSBhIHNlcnZlci4NClRoaXMgaGFzIG1vcmUgYXV0aG9yaXR5IHRo
YW4gdGhlIEFDQ0VTU19QT1JUIGJpbmRpbmcuICBUaGVyZWZvcmUgdGhpcw0KYmluZGluZydzIHN0
YXRlIGlzIERIQ1BfQVNTSUdORUQuDQoNCkNvbXBhcmlzb24gb2YgdGhlc2UgYmluZGluZ3MgdGhl
cmVmb3JlIGJlY29tZXMgc2ltcGxlcjogREhDUF9BU1NJR05FRCB2cw0KQ0dBX0FVVEhFTlRJQ0FU
RUQNCg0KUGVyaGFwcyBzb21lIGNsYXJpZnlpbmcgd29yZHMgY291bGQgYmUgcHV0IGludG8gdGhl
IGRyYWZ0Pw0KDQogIDwvUFJFPjwvQkxPQ0tRVU9URT4NCjxESVY+SSBndWVzcyBzby4gSWYgdGhp
cyB3YXMgbm90IGNyeXN0YWwgY2xlYXIgaW4gdGhlIGN1cnJlbnQgd3JpdGluZywgaXQgbWVhbnMg
DQpJIG5lZWQgdG8gY2xhcmlmeS4mbmJzcDsgWW91IGdvdCBpdCBhbGxyaWdodCB0aG91Z2gsIDxC
Uj5zbyBpdCBtdXN0IG5vdCBoYXZlIA0KYmVlbiB0b28gYmFkIDopPEJSPk1heWJlIEknbGwgYWRk
IGFuIGV4YW1wbGUgd2l0aCBzb21lIHZhbHVlcyANCi4uLjxCUj5UaGFua3M8QlI+ZXJpYzwvRElW
Pg0KPERJVj5bRG9uZ10gQnV0IEl0IHNlZW1zIHRoZXJlIGlzIHNvbWV0aGluZyBkaWZmZXJlbnQm
bmJzcDsgYmV0d2VlbiBHcmVnJ3MgDQp1bmRlcnN0YW5kaW5nIGFuZCB5b3VyIGV4cGxhbmF0aW9u
LiBTbyBhZ3JlZSB0byBhZGQgPC9ESVY+DQo8RElWPnNvbWUgY2xhcmlmaWNhdGlvbiBhcyBteSBs
YXN0IG1haWwgc2FpZC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPltEb25nXSBJbiBh
ZGRpdGlvbiwgSSdtIHdvcnJpZWQgYWJvdXQgYSBwb3NzaWJsZSBzZWN1cml0eSBwcm9ibGVtLjwv
RElWPg0KPERJVj4qKioqKioqKioqKioqPC9ESVY+DQo8RElWPlRoZSBkcmFmdCBzYXlzOjwvRElW
Pg0KPERJVj4mbmJzcDsmbmJzcDsgVGhlcmVmb3JlLCBhIGRhdGEgcGFja2V0IHNob3VsZCBub3Qg
YmUgdXNlZCB0byBjb21wbGV0ZSANCnRoZTxCUj4mbmJzcDsmbmJzcDsgYmluZGluZyBlbnRyeSwg
YnV0IG9ubHkgYXMgYSBoaW50IHRoYXQgaXQgc2hvdWxkIHNlZWsgZm9yIA0KY29tcGxldGlvbi48
QlI+Jm5ic3A7Jm5ic3A7IFVwb24gcmVjZWl2aW5nIGEgZGF0YSBwYWNrZXQgY2FycnlpbmcgYSBz
b3VyY2UgDQphZGRyZXNzIG5vdCBzZWVuPEJSPiZuYnNwOyZuYnNwOyBiZWZvcmUsIHRoZSBzd2l0
Y2ggc2hvdWxkIGlzc3VlIGEgREFEIHBhY2tldCBvbiANCnRoZSBsaW5rIChhbGwgcG9ydHM8QlI+
Jm5ic3A7Jm5ic3A7IG9mIHRoZSB2bGFuKSwgaW5jbHVkaW5nIHRoZSBvbmUgZnJvbSB3aGljaCAN
CnRoZSBkYXRhIHBhY2tldCB3YXM8QlI+Jm5ic3A7Jm5ic3A7IHJlY2VpdmVkLiZuYnNwOyBUaGUg
YWRkcmVzcyBvd25lciBpcyANCmV4cGVjdGVkIHRvIHJlc3BvbmQgd2l0aCBhbiBOQSw8QlI+Jm5i
c3A7Jm5ic3A7IGNhcnJ5aW5nIENHQSBjcmVkZW50aWFscyBpZiANCmFueS4mbmJzcDsgVXBvbiBy
ZWNlaXZpbmcgdGhpcyByZXNwb25zZSwgdGhlPEJSPiZuYnNwOyZuYnNwOyBzd2l0Y2ggY2FuIGNv
bXBsZXRlIA0KdGhlIGJpbmRpbmcgZW50cnkgYW5kIHN0YXJ0IGZvcndhcmRpbmcgdHJhZmZpYzxC
Uj4mbmJzcDsmbmJzcDsgZnJvbSB0aGUgDQpzb3VyY2UuPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNw
OyAuLi48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7IEZvciBpbnN0YW5jZSwgdXBvbiByZWNlaXZp
bmcgYSBkYXRhIHBhY2tldCwgDQp0aGU8QlI+Jm5ic3A7Jm5ic3A7IHN3aXRjaCB3aWxsIGlzc3Vl
IGEgREFEIE5TIGFuZCB3YWl0IGZvciBhbiBOQS4mbmJzcDsgQmVmb3JlIA0KcmVjZWl2aW5nIHRo
ZTxCUj4mbmJzcDsmbmJzcDsgTkEsIHRoZSBlbnRyeSBpcyBJTUNPTVBMRVRFLiZuYnNwOyBUaGVu
IGl0IG1vdmVzIA0KdG8gUkVBQ0hBQkxFLiZuYnNwOyBUaGVuIHRvPEJSPiZuYnNwOyZuYnNwOyBT
VEFMRSB1bmxlc3MgdGhlIGJpbmRpbmcgaXMgDQpjb25maXJtZWQgYnkgbW9yZSBORFAgdHJhZmZp
Yy48QlI+KioqKioqKioqKioqPEJSPlRoaW5raW5nIGFib3V0IGFuIGF0dGFja2VyIA0Kc2VuZHMg
ZGF0YSBwYWNrZXRzIHdpdGggZGlmZmVyZW50IGZvcmdlZCBzb3VyY2UgYWRkcmVzc2VzIGluY2Vz
c2FudGx5LiBUaGVuIA0KdGhlc2UgZGF0YSBwYWNrZXRzIGxlYWQgPC9ESVY+DQo8RElWPnRoZSZu
YnNwO3Nhdmkgc3dpdGNoIHRvIHNlbmQgREFEIGFuZCB3YWl0IGZvciBOQSByZXNwb25zZS4mbmJz
cDtJbiB0aGlzIA0KY2FzZSwgYSBEb1MgYXR0YWNrIGFyaXNlLiBUaGUgc2VjdXJpdHkgY29uc2lk
ZXJhdGlvbiBzaG91bGQgYmUgYWRkZWQuPC9ESVY+DQo8RElWPkFuZCB0aGUgZW50cnkgYmluZGlu
Z3Mgd2l0aCBJTUNPTVBMRVRFIHN0YXRlIGNvc3QgdGhlIG1lbW9yeSB3aGlsZSB3YWl0aW5nIA0K
Zm9yIHRoZSByZXNwb25zZS4mbmJzcDtNYXliZSBhIHN0YXRlIG1hY2hpbmUgaXMgbmVlZCBmb3Ig
PC9ESVY+DQo8RElWPnRoZSBzdGF0ZSB0cmFuc2l0aW9uLiZuYnNwO1RoZSZuYnNwO2JlaGF2aW9y
IG9mJm5ic3A7c2F2aSBzd2l0Y2ggbWlnaHQgYmUgDQpzb21ldGhpbmcgbGlrZSB0aGlzOjwvRElW
Pg0KPERJVj5UcmlnZ2VyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEFjdGlvbjwv
RElWPg0KPERJVj5SZWNlaXZlIGEgZGF0YSANCnBhY2tldCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyBDcmVh
dGUgYSBJTUNPTVBMRVRFIGVudHJ5LCBzZW5kJm5ic3A7REFEJm5ic3A7TlM8L0RJVj4NCjxESVY+
SWYgcmVjZWl2ZSBhIE5BIHdpdGhpbiB4KHRoZSBleGFjdCBzZWNvbmRzLCBlLmcuIDNzJm5ic3A7
KSZuYnNwOyZuYnNwOyANCklNQ09NUExFVEUgbW92ZXMgdG8gUkVBQ0hBQkxFPC9ESVY+DQo8RElW
PklmIHJlY2VpdmUgbm8gTkEgd2l0aGluIA0KeCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkVsZW1pbmF0ZSB0aGUg
SU1DT01QTEVURSBlbnRyeTwvRElWPg0KPERJVj4uLi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQou
Li48QlI+PC9ESVY+DQo8RElWPlRoYW5rIHlvdS48L0RJVj4NCjxESVY+RG9uZzwvRElWPg0KPEJM
T0NLUVVPVEUgDQpjaXRlPW1pZDo2OTgzQkY5N0JGQzI0RDRFQTU1MUYxNDA3MTIzMjkxODAxMUNF
RjAyQG1lbG1haWwubmV0c3Rhcm5ldHdvcmtzLmNvbSANCnR5cGU9ImNpdGUiPjxQUkUgd3JhcD0i
Ij5QbGVhc2Ugbm90ZSB0aGF0IGFuIGFkZHJlc3MgYmluZGluZyBjYW4gYmUgYm90aCBDR0EgQXV0
aGVudGljYXRlZCBhbmQNCkRIQ1B2NiBhc3NpZ25lZCwgc2luY2UNCmEgbm9kZSBjYW4gcHJvcG9z
ZSBpdHMgYWRkcmVzcyBpbiBESENQdjYgYmFzZWQgb24ga25vd24gYWRkcmVzcw0KcHJlZml4ZXMu
ICBJbiB0aGlzIGNhc2UsDQp0aGUgZmFjdCB0aGF0IHRoZSBkZXZpY2UgY2FuIHBlcmZvcm0gU0VO
RCBDR0EgQXV0aCBvbiB0aGUgYWRkcmVzcyBsZW5kcw0KbW9yZSBhdXRob3JpdHkgdG8gdGhlDQpi
aW5kaW5nIChnaXZpbmcgQ0dBX0FVVEhFTlRJQ0FURUQpIHN0YXRlLg0KDQoNClNpbmNlcmVseSwN
Cg0KR3JlZyBEYWxleQ0KU2VjdXJpdHkgQ29uc3VsdGFudA0KTmV0U3RhciBBdXN0cmFsaWEgUHR5
IEx0ZA0KDQpFLW1haWw6IDxBIGNsYXNzPW1vei10eHQtbGluay1hYmJyZXZpYXRlZCBocmVmPSJt
YWlsdG86Z2RhbGV5QG5ldHN0YXJuZXR3b3Jrcy5jb20iPmdkYWxleUBuZXRzdGFybmV0d29ya3Mu
Y29tPC9BPg0KTW9iaWxlOiArNjEgNDAxIDc3MiA3NzANCkRpcmVjdDogKzYxIDMgODUzMiA0MDQy
DQpGYXg6ICAgICs2MSAzIDg1MzIgNDAzMiANCg0KICA8L1BSRT48L0JMT0NLUVVPVEU+DQo8RElW
PjxCUj48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg==

--Boundary_(ID_BoD81j7cFHOTvMKMgiFqpg)--

From elevyabe@cisco.com  Thu Aug  6 01:35:12 2009
Return-Path: 
X-Original-To: savi@core3.amsl.com
Delivered-To: savi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BC03A6D66 for ; Thu,  6 Aug 2009 01:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.188
X-Spam-Level: 
X-Spam-Status: No, score=-9.188 tagged_above=-999 required=5 tests=[AWL=0.811,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EFQWkwEhjYf for ; Thu,  6 Aug 2009 01:35:11 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C64F13A6D52 for ; Thu,  6 Aug 2009 01:34:37 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQAAAozekqQ/uCLe2dsb2JhbACaRQEBFiQGoG2GZIFGkEYFgS6CIkiCIg
X-IronPort-AV: E=Sophos;i="4.43,332,1246838400"; d="scan'208";a="46559490"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Aug 2009 08:34:39 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n768YdbM000639;  Thu, 6 Aug 2009 10:34:39 +0200
Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n768YdfZ004093; Thu, 6 Aug 2009 08:34:39 GMT
Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 6 Aug 2009 10:34:39 +0200
Received: from [144.254.53.100] ([144.254.53.100]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 6 Aug 2009 10:34:39 +0200
Message-ID: <4A7A95A3.9020304@cisco.com>
Date: Thu, 06 Aug 2009 10:34:43 +0200
From: Eric Levy-Abegnoli 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Dong Zhang 
References: <4A784771.6000600@cisco.com> <200908051021361825410@huaweisymantec.com> <6983BF97BFC24D4EA551F14071232918011CEF02@melmail.netstarnetworks.com> <4A7985C2.4040003@cisco.com> <200908061004324896481@huaweisymantec.com>
In-Reply-To: <200908061004324896481@huaweisymantec.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 06 Aug 2009 08:34:39.0093 (UTC) FILETIME=[BCAAAA50:01CA1670]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2985; t=1249547679; x=1250411679; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20Question=20for=20draft-levy-ab egnoli-savi-plbt-01 |Sender:=20; bh=ko51n6pPrAh5TgCOaApb/YgnEbupHWwu08JePgeUVwc=; b=UpL6KaYZsLudjiUSCDJEmNcaUX0gnVl6m62dZeltUX/vAs1P/AeoD0SpM1 JyVPd0SCsasKaskQge9XWUaSHkx6ymUkNkECBNpWvSU83c6GVpXOZHmrZHsf 0OIT3QHfKZ;
Authentication-Results: ams-dkim-2; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
Cc: SAVI Mailing List , Greg Daley 
Subject: Re: [savi] Question for draft-levy-abegnoli-savi-plbt-01
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the SAVI WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Aug 2009 08:35:12 -0000

Hi Dong,
thanks for all the good points. See inline ...

Dong Zhang a ¨¦crit :
> Hi Eric,
> Please check inline.
>
[snip]
> I guess so. If this was not crystal clear in the current writing, it
> means I need to clarify. You got it allright though,
> so it must not have been too bad :)
> Maybe I'll add an example with some values ...
> Thanks
> eric
> [Dong] But It seems there is something different between Greg's
> understanding and your explanation. So agree to add
> some clarification as my last mail said.
will do in the next version

> [Dong] In addition, I'm worried about a possible security problem.
> *************
> The draft says:
> Therefore, a data packet should not be used to complete the
> binding entry, but only as a hint that it should seek for completion.
> Upon receiving a data packet carrying a source address not seen
> before, the switch should issue a DAD packet on the link (all ports
> of the vlan), including the one from which the data packet was
> received. The address owner is expected to respond with an NA,
> carrying CGA credentials if any. Upon receiving this response, the
> switch can complete the binding entry and start forwarding traffic
> from the source.
> ...
> For instance, upon receiving a data packet, the
> switch will issue a DAD NS and wait for an NA. Before receiving the
> NA, the entry is IMCOMPLETE. Then it moves to REACHABLE. Then to
> STALE unless the binding is confirmed by more NDP traffic.
> ************
> Thinking about an attacker sends data packets with different forged
> source addresses incessantly. Then these data packets lead
> the savi switch to send DAD and wait for NA response. In this case, a
> DoS attack arise. The security consideration should be added.
> And the entry bindings with IMCOMPLETE state cost the memory while
> waiting for the response. Maybe a state machine is need for
> the state transition. The behavior of savi switch might be something
> like this:
> Trigger Action
> Receive a data packet Create a IMCOMPLETE entry, send DAD NS
> If receive a NA within x(the exact seconds, e.g. 3s ) IMCOMPLETE moves
> to REACHABLE
> If receive no NA within x Eleminate the IMCOMPLETE entry
> ...
All this is very true. Actually, in the -00 of this draft, I had
included a state machine description, somewhat very close to what you
are describing. I removed it in this -01 version to focus on
the preference algorithm (problem statement and proposed solution) and
give a chance to people to review that bit.
>From there it really depend on where this is going: if some of this
draft endup in the WG document (fcfs or with a different name as it was
suggested in Stockholm), then I would really like to
see a state machine there (I don't think there is one in fcfs).
If this is going to be a separate document, them I agree that I should
put back the state machine and clarify the security issues.
Eric

> ...
> Thank you.
> Dong