From nobody Tue Jun 2 13:34:19 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311F81B3004 for ; Tue, 2 Jun 2015 13:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrKWH_FIWs-c for ; Tue, 2 Jun 2015 13:34:15 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43B01B2FFF for ; Tue, 2 Jun 2015 13:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2600; q=dns/txt; s=iport; t=1433277254; x=1434486854; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yULlABJjQ3jxH5X7jwRhGnxdP1Tp4DlbqqFYHChGrLQ=; b=Kzm9rzhHiYorDEHGKOiUMSEyTmiP/k/ZnYg4B4a97u90kHjdwhNjpGiA ybJYGG2pwfITGrdGZ3Hs31wY0rAOQIwFG4rkAccuN3DqQ5qSkdHKmUkIQ 2tM6hkzZumSTXtogpMYdJe55dmZPvLXcM0JT8Eu+nw6WE2mfeeGwFA+fN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4BADUEW5V/5ldJa1bgxCBMgaDGLtTCYdRAhyBJzgUAQEBAQEBAYEKhCIBAQEDASMRUQYBGQEDAQEDAgYdAwIEHxEUAQIGCQEEARIIiBADCgi2R55hDYUtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiiKCTYFqHhYogmIvgRYFkxCJOpIPhwUjYYMXb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,541,1427760000"; d="scan'208";a="155661878" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 02 Jun 2015 20:34:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t52KYE8b025851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jun 2015 20:34:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.169]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 15:34:13 -0500 From: "Bernie Volz (volz)" To: "int-dir@ietf.org" , "int-ads@tools.ietf.org" Thread-Topic: Review - [Int-dir] INT Dir review: draft-ietf-6tisch-architecture Thread-Index: AdCdc234EGcVzL4mS8mO/mkdRCT2GA== Date: Tue, 2 Jun 2015 20:34:13 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CB015D1@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.36.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Int-dir] Review - INT Dir review: draft-ietf-6tisch-architecture X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 20:34:17 -0000 V2hpbGUgb25seSBhIHBhcnRpYWwgcmV2aWV3LCB0aGVzZSBjb21tZW50cyBtYXkgc3RpbGwgaGF2 ZSBzb21lIHZhbHVlIHRvIHRoZSBBRHMuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBqaW5tZWkudGF0dXlhQGdtYWlsLmNvbSBbbWFpbHRvOmppbm1laS50 YXR1eWFAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgPz8/Pw0KU2VudDogVHVlc2RheSwgSnVuZSAw MiwgMjAxNSAyOjIzIFBNDQpUbzogQmVybmllIFZvbHogKHZvbHopDQpDYzogQ2hyaXN0b3BoZXIg TElMSkVOU1RPTFBFIChjZGxAYXNnYWFyZC5vcmcpOyBTaGVuZyBKaWFuZyAoamlhbmdzaGVuZ0Bo dWF3ZWkuY29tKQ0KU3ViamVjdDogUmU6IFJldmlld2VyIFJlcXVlc3QgLSBbSW50LWRpcl0gSU5U IERpciByZXZpZXc6IGRyYWZ0LWlldGYtNnRpc2NoLWFyY2hpdGVjdHVyZQ0KDQpBdCBNb24sIDEg SnVuIDIwMTUgMTM6MjE6MjkgKzAwMDAsDQoiQmVybmllIFZvbHogKHZvbHopIiA8dm9sekBjaXNj by5jb20+IHdyb3RlOg0KDQo+ID4+IEdpdmUgU2hlbmcgYSBmZXcgbW9yZSBkYXlzLCBhbmQgaWYg SSBkb24ndCBoZWFyIGZyb20gaGltIGJ5IE1vbmRheSwgSSBjYW4gYXNzaWduIHlvdS4NCj4gPg0K PiA+QWgsIG9rYXkuICBJbiB0aGF0IGNhc2UgSSdsbCBqdXN0IGhvbGQgb2ZmIHVudGlsL3VubGVz cyBJJ20gZXhwbGljaXRseSBhc2tlZCBmb3IgYSByZXZpZXcuDQo+DQo+IEFzIFNoZW5nIGRpZG4n dCByZXNwb25kLCBiZSBncmVhdCBpZiB5b3UgY291bGQgZG8gdGhlIHJldmlldyENCg0KSSd2ZSBn b25lIHRocm91Z2ggdGhlIGRyYWZ0LCBidXQgKGFzIEkgd2FzIGFmcmFpZCkgSSBkaWRuJ3Qgc2Vl bSB0byBiZSBhYmxlIHRvIHByb3ZpZGUgdmVyeSB1c2VmdWwgZmVlZGJhY2suICBPdmVyYWxsIGl0 J3Mgd2VsbCB3cml0dGVuLCBidXQgSSdtIG5vdCBmYW1pbGlhciB3aXRoIG1hbnkgb2YgdGhlIGJh Y2tncm91bmQgdG9waWNzIGxpc3RlZCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24g MjoNCg0KICAgUmVhZGVycyBhcmUgZXhwZWN0ZWQgdG8gYmUgZmFtaWxpYXIgd2l0aCBhbGwgdGhl IHRlcm1zIGFuZCBjb25jZXB0cw0KICAgdGhhdCBhcmUgZGlzY3Vzc2VkIGluICJOZWlnaGJvciBE aXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiINCiAgIFtSRkM0ODYxXSwgIklQdjYgb3ZlciBMb3ct UG93ZXIgV2lyZWxlc3MgUGVyc29uYWwgQXJlYSBOZXR3b3Jrcw0KICAgKDZMb1dQQU5zKTogT3Zl cnZpZXcsIEFzc3VtcHRpb25zLCBQcm9ibGVtIFN0YXRlbWVudCwgYW5kIEdvYWxzIg0KICAgW1JG QzQ5MTldLCBOZWlnaGJvciBEaXNjb3ZlcnkgT3B0aW1pemF0aW9uIGZvciBMb3ctcG93ZXIgYW5k IExvc3N5DQogICBOZXR3b3JrcyBbUkZDNjc3NV0gd2hlcmUgdGhlIDZMb1dQQU4gUm91dGVyICg2 TFIpIGFuZCB0aGUgNkxvV1BBTg0KICAgQm9yZGVyIFJvdXRlciAoNkxCUikgYXJlIGludHJvZHVj ZWQsIGFuZCAiTXVsdGktbGluayBTdWJuZXQgU3VwcG9ydA0KICAgaW4gSVB2NiIgW0ktRC5pZXRm LWlwdjYtbXVsdGlsaW5rLXN1Ym5ldHNdLg0KDQpzbyBJIGNhbid0IHNheSB3aXRoIGNvbmZpZGVu Y2UgaWYgdGhpcyBkb2N1bWVudCBpcyB0ZWNobmljYWxseSBzb3VuZC4NCg0KVGhlIG9ubHkgc2Vj dGlvbiBJJ20gcmVsYXRpdmVseSBjb21mb3J0YWJsZSB3aXRoIGlzIFNlY3Rpb24gNi40OiBpdCBs b29rZWQgZmluZSB0byBtZS4gIEJleW9uZCB0aGF0IG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRy YWZ0IGlzIHF1aXRlIHN1cGVyZmljaWFsLg0KDQpJIGd1ZXNzIHNvbWVvbmUgZmFtaWxpYXIgd2l0 aCB0aGUgdG9waWNzIGxpc3RlZCBhYm92ZSB3aWxsIG5lZWQgdG8gcmV2aWV3IGl0Lg0KDQotLQ0K SklOTUVJLCBUYXR1eWENCg== From nobody Mon Jun 8 08:39:41 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338831B2EDE for ; Mon, 8 Jun 2015 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.111 X-Spam-Level: X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6jBdnpTAyt1 for ; Mon, 8 Jun 2015 08:39:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208AE1B2EAD for ; Mon, 8 Jun 2015 08:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5611; q=dns/txt; s=iport; t=1433777917; x=1434987517; h=from:to:cc:subject:date:message-id:mime-version; bh=QF1N5PRhZknE/XynRHVj+6Qq60WFuvWx1imH7m9iHFs=; b=D9DYUyZgFnvNkTwtUwtbZOThOKU7GxM0ZYJAIqMU5rq7qf+uJFWa4BNu ZNJzmlxL5Ru+IiSGCuezTw84HqJZ2TrqQofBl/sAQTo51rKmmnJSSdoHW DB9vjI3LgrQT0RA9jW5ASES3zSPrD4kKVe6qlNHMVaVE45SlYrmzaRvB9 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CwBQCHtXVV/5RdJa1cgxBUXgaDGLpvb4FdhXmBKjkTAQEBAQEBAYEKhCUEI1YSAUoCNCcEAQ0OBYgfDaldo0kBAQEBAQEBAQEBAQEBAQEBAQEaj35LAg6CXy+BFgWQZIJKghiBR4dLl10kg3dvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,574,1427760000"; d="asc'?scan'208";a="157286384" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 08 Jun 2015 15:38:36 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t58Fcahi004473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jun 2015 15:38:36 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 8 Jun 2015 10:38:36 -0500 From: "Carlos Pignataro (cpignata)" To: "int-dir@ietf.org" , "int-ads@tools.ietf.org" Thread-Topic: Int-Dir Review of draft-ietf-pcp-authentication-09 Thread-Index: AQHQogEub95QBEtuwkuwpMiuQmYptQ== Date: Mon, 8 Jun 2015 15:38:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.55.36] Content-Type: multipart/signed; boundary="Apple-Mail=_998EB6BF-B97F-4D95-A3F0-7A2FA4C3DEDC"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "pcp-chairs@tools.ietf.org" , "draft-ietf-pcp-authentication@tools.ietf.org" Subject: [Int-dir] Int-Dir Review of draft-ietf-pcp-authentication-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:39:40 -0000 --Apple-Mail=_998EB6BF-B97F-4D95-A3F0-7A2FA4C3DEDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I am an assigned INT directorate reviewer for = draft-ietf-pcp-authentication-09. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. Summary: This document describes an EAP-based Authentication mechanism for the = Port Control Protocol (PCP), meeting the security requirements of the = Advanced Threat Model in the base PCP specification. Its intended status = is Standards Track. This is a very well written document. I only found minor issues (e.g., = option-lengths), editorials and nits. Major Issues: None. Minor Issues, Nits, Editorials: I hope you find these useful: General: CMP: There are variations of =E2=80=9Csession ID=E2=80=9D vs. = =E2=80=9CSession-ID=E2=80=9D vs. =E2=80=9CSession_ID=E2=80=9D and = others. Same with =E2=80=9Copcode=E2=80=9D vs. =E2=80=9COpcode=E2=80=9D = and others, which should be normalized. 1. Introduction This document proposes a PCP security extension which enables PCP servers to authenticate their clients with Extensible Authentication Protocol (EAP). CMP: s/which/that/ CMP: Does this document =E2=80=9Cproposes=E2=80=9D or =E2=80=9Cdescribes=E2= =80=9D / =E2=80=9Cdefines"? 2. Terminology PCP Client: A PCP software instance which is responsible for issuing CMP: s/which/that/ [there are a couple more instances of this] 5.X. For all the 5.X sections, starting from 5.3: CMP: Reserved =E2=80=94 could we specify the treatment of Reserved bits = (e.g., MBZ)? Like =E2=80=9CReserved: MUST be zero on transmission and = MUST be ignored on reception." CMP: What follows is some potential issues with Option-Lengths. I might = be missing something. 5.3. Nonce Option Option-Length: The length of the Nonce Option (in octets), including the 4 octet fixed header and the variable length of the authentication data. CMP: The format of the figure does not show any Authentication Data. Is = this Option-Length always 4? 5.4. Authentication Tag Option for Common PCP Messages Option-Length: The length of the Authentication Tag Option for Common PCP (in octets), including the 12 octet fixed header and the variable length of the authentication data. CMP: Is it necessary to clarify that when the Auth Data is padded, the = length still reflects the unpadded data length? 5.5. Authentication Tag Option for PA Messages Option-Length: The length of the Authentication Tag Option for PCP Auth (in octet), including the 12 octet fixed header and the variable length of the authentication data. CMP: This one seems to only include 4 (and not 12) octets of fixed = header. 5.6. EAP Payload Option Option-Length: The length of the EAP Payload Option (in octets), including the 4 octet fixed header and the variable length of the EAP message. CMP: What is the fixed header in this one? 5.7. PRF Option Option-Length: The length of the PRF Option (in octets), including the 4 octet fixed header and the variable length of the EAP message. CMP: What is the variable length in this one? Is it always 4? 7. IANA Considerations Opcodes is maintained in http://www.iana.org/ assignments/pcp- parameters): CMP: The URLs pointing to pcp-parameters are broken. TBA Authentication Opcode. CMP: An editorial suggestion, it help with readability of this section = to indent the actual assignments for PCP Opcode and PCP Option Codes, = such as it is done with PCP result codes: TBA INITIATION: The client indication to the server for authentication. Maximum occurences: 1. CMP: s/occurences/occurrences/g References: CMP: Idnits finds these two: ** Downref: Normative reference to an Informational RFC: RFC 5281 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Thanks! =E2=80=94 Carlos. --Apple-Mail=_998EB6BF-B97F-4D95-A3F0-7A2FA4C3DEDC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVdbb/AAoJEIXgpQGOZny9qaAP/2fde9rooVEM6HHBvhPQXV30 DkoB0iR+Amag8M2gaFZGdDs8twLxVFh5om7Zn9noiIp8dooqm4VyWjPGCJuGcvUo 7moFQtMPA/zUE8PIKOknivzD7ngPifRkQTIt959BYc2U74WCBQi6j3obk4RJxHDa VIe7IB7pMG6Psrid0QQVPoabaI02wxE9RZ2G8DOmURICAgPPiYhaiIikTRl969tW 0jC/zSHELHxlettAoae5FQRCy0GTsOy7u1NEmJj69fzS+uJUszf0aekdOvQlIGh9 z3uRMGbnVZl4E39fINFeqMPCU2wkukYi8+L9QplJcsQCBaElHyGWpGstSnAKEcZf Jh5sx+XG0Hcplhgd8OIXOX4xbwjAyC4Hli9MtjD83NcGSekCySE0wP8BDrf0sScB 667EMDSOPULKZyg861CLwanv/lwitsLcSJP/VPEC6A4s6QNDfH05v/u4geYuekeV 3aHwiDBvytMZeVWtcJQdo7E1ldtEm004qNh611reUxtApckgEOdOF00Lk6fhDcGe nMNULfMiHcrW/5oNzeXF3whfdCECmYk1lOUyUwp6dC0rPua+ilTeX8DBmnHbk0h/ MJF7fE7m87ftBKQ0/OoOgqoLsh86b65FxI0l86omCql7rZivEC3n5GY+s5k+oYf2 r4AtVwt584NU95EmDXfs =Rwu1 -----END PGP SIGNATURE----- --Apple-Mail=_998EB6BF-B97F-4D95-A3F0-7A2FA4C3DEDC-- From nobody Tue Jun 9 07:13:55 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9061B29DD for ; Tue, 9 Jun 2015 00:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKQvBSC2_iQl for ; Tue, 9 Jun 2015 00:19:30 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99011B29DF for ; Tue, 9 Jun 2015 00:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8552; q=dns/txt; s=iport; t=1433834370; x=1435043970; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mb4o0a+2yLbzo0Gx+MwsEsuTaFREjChF5AM/b2aT08Q=; b=GTh0lwdzMyibFBTG/QFLNulh3tosSFKp4OpPnPxqJJH3DaIfwiH7f/cO SV2V4xrckJ8I1qvinry/M20p3VGJYgUYU7lmaRFx9mHEx4AE6C55hM91C aaMG0GkVnHlPDMLjsPcHMyd7blIKbztwjw2/CirbmtCqaYPh6yJytTbXB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C3BABWknZV/5RdJa1cgxBUXgaDGLpvZgmBYYV5AhyBGTgUAQEBAQEBAYEKhCIBAQEBAgEjETcODAQCAQgRBAEBAwIGIAICAjAVCAgCBAENBQgBiB0IDap9pCEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKIoQ7GjEHBoJiL4EWBZBtgk+EQogeQIM7kjokg3hvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,579,1427760000"; d="scan'208";a="157519725" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP; 09 Jun 2015 07:19:29 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t597JTBE027168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jun 2015 07:19:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 9 Jun 2015 02:19:29 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Carlos Pignataro (cpignata)" , "int-dir@ietf.org" , "int-ads@tools.ietf.org" Thread-Topic: Int-Dir Review of draft-ietf-pcp-authentication-09 Thread-Index: AQHQogEub95QBEtuwkuwpMiuQmYptZ2jfvXw Date: Tue, 9 Jun 2015 07:19:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47866B6A@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.79.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 09 Jun 2015 07:13:53 -0700 Cc: "pcp-chairs@tools.ietf.org" , "draft-ietf-pcp-authentication@tools.ietf.org" Subject: Re: [Int-dir] Int-Dir Review of draft-ietf-pcp-authentication-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 07:19:33 -0000 SGkgQ2FybG9zLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2FybG9zIFBpZ25hdGFybyAo Y3BpZ25hdGEpDQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAwOCwgMjAxNSA5OjA5IFBNDQo+IFRvOiBp bnQtZGlyQGlldGYub3JnOyBpbnQtYWRzQHRvb2xzLmlldGYub3JnDQo+IENjOiBkcmFmdC1pZXRm LXBjcC1hdXRoZW50aWNhdGlvbkB0b29scy5pZXRmLm9yZzsgcGNwLWNoYWlyc0B0b29scy5pZXRm Lm9yZw0KPiBTdWJqZWN0OiBJbnQtRGlyIFJldmlldyBvZiBkcmFmdC1pZXRmLXBjcC1hdXRoZW50 aWNhdGlvbi0wOQ0KPiANCj4gSGksDQo+IA0KPiBJIGFtIGFuIGFzc2lnbmVkIElOVCBkaXJlY3Rv cmF0ZSByZXZpZXdlciBmb3IgZHJhZnQtaWV0Zi1wY3AtYXV0aGVudGljYXRpb24tMDkuDQo+IA0K PiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBv ZiB0aGUgSW50ZXJuZXQgQXJlYQ0KPiBEaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIHNo ZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQo+IGxpa2UgdGhleSB3 b3VsZCB0cmVhdCBjb21tZW50cyBmcm9tIGFueSBvdGhlciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQg cmVzb2x2ZQ0KPiB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyB0 aGF0IGhhdmUgYmVlbiByZWNlaXZlZC4gRm9yDQo+IG1vcmUgZGV0YWlscyBvbiB0aGUgSU5UIERp cmVjdG9yYXRlLCBzZWUNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0 bWwuDQo+IA0KPiBTdW1tYXJ5Og0KPiANCj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gRUFQ LWJhc2VkIEF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBmb3IgdGhlIFBvcnQNCj4gQ29udHJvbCBQ cm90b2NvbCAoUENQKSwgbWVldGluZyB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBB ZHZhbmNlZA0KPiBUaHJlYXQgTW9kZWwgaW4gdGhlIGJhc2UgUENQIHNwZWNpZmljYXRpb24uIEl0 cyBpbnRlbmRlZCBzdGF0dXMgaXMgU3RhbmRhcmRzDQo+IFRyYWNrLg0KPiANCj4gVGhpcyBpcyBh IHZlcnkgd2VsbCB3cml0dGVuIGRvY3VtZW50LiBJIG9ubHkgZm91bmQgbWlub3IgaXNzdWVzIChl LmcuLCBvcHRpb24tDQo+IGxlbmd0aHMpLCBlZGl0b3JpYWxzIGFuZCBuaXRzLg0KPiANCj4gTWFq b3IgSXNzdWVzOg0KPiANCj4gTm9uZS4NCj4gDQo+IE1pbm9yIElzc3VlcywgTml0cywgRWRpdG9y aWFsczoNCj4gDQo+IEkgaG9wZSB5b3UgZmluZCB0aGVzZSB1c2VmdWw6DQo+IA0KPiBHZW5lcmFs Og0KPiANCj4gQ01QOiBUaGVyZSBhcmUgdmFyaWF0aW9ucyBvZiDigJxzZXNzaW9uIElE4oCdIHZz LiDigJxTZXNzaW9uLUlE4oCdIHZzLiDigJxTZXNzaW9uX0lE4oCdIGFuZA0KPiBvdGhlcnMuIFNh bWUgd2l0aCDigJxvcGNvZGXigJ0gdnMuIOKAnE9wY29kZeKAnSBhbmQgb3RoZXJzLCB3aGljaCBz aG91bGQgYmUNCj4gbm9ybWFsaXplZC4NCg0KRml4ZWQuDQoNCj4gDQo+IDEuICBJbnRyb2R1Y3Rp b24NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBQQ1Agc2VjdXJpdHkNCj4gICAg ZXh0ZW5zaW9uIHdoaWNoIGVuYWJsZXMgUENQIHNlcnZlcnMgdG8gYXV0aGVudGljYXRlIHRoZWly IGNsaWVudHMNCj4gICAgd2l0aCBFeHRlbnNpYmxlIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIChF QVApLg0KPiANCj4gQ01QOiBzL3doaWNoL3RoYXQvDQoNCkZpeGVkLg0KDQo+IA0KPiBDTVA6IERv ZXMgdGhpcyBkb2N1bWVudCDigJxwcm9wb3Nlc+KAnSBvciDigJxkZXNjcmliZXPigJ0gLyDigJxk ZWZpbmVzIj8NCg0KImRlZmluZXMiIHNlZW1zIHRvIGZpdHMgYmV0dGVyLg0KDQo+IA0KPiAyLiAg VGVybWlub2xvZ3kNCj4gDQo+ICAgIFBDUCBDbGllbnQ6IEEgUENQIHNvZnR3YXJlIGluc3RhbmNl IHdoaWNoIGlzIHJlc3BvbnNpYmxlIGZvciBpc3N1aW5nDQo+IA0KPiBDTVA6IHMvd2hpY2gvdGhh dC8gW3RoZXJlIGFyZSBhIGNvdXBsZSBtb3JlIGluc3RhbmNlcyBvZiB0aGlzXQ0KDQpGaXhlZC4N Cg0KPiANCj4gNS5YLiAgRm9yIGFsbCB0aGUgNS5YIHNlY3Rpb25zLCBzdGFydGluZyBmcm9tIDUu MzoNCj4gDQo+IENNUDogUmVzZXJ2ZWQg4oCUIGNvdWxkIHdlIHNwZWNpZnkgdGhlIHRyZWF0bWVu dCBvZiBSZXNlcnZlZCBiaXRzIChlLmcuLCBNQlopPw0KPiBMaWtlIOKAnFJlc2VydmVkOiBNVVNU IGJlIHplcm8gb24gdHJhbnNtaXNzaW9uIGFuZCBNVVNUIGJlIGlnbm9yZWQgb24NCj4gcmVjZXB0 aW9uLiINCg0KWWVzLCB1cGRhdGVkLg0KDQo+IA0KPiBDTVA6IFdoYXQgZm9sbG93cyBpcyBzb21l IHBvdGVudGlhbCBpc3N1ZXMgd2l0aCBPcHRpb24tTGVuZ3Rocy4gSSBtaWdodCBiZQ0KPiBtaXNz aW5nIHNvbWV0aGluZy4NCj4gDQo+IDUuMy4gIE5vbmNlIE9wdGlvbg0KPiANCj4gICAgICAgT3B0 aW9uLUxlbmd0aDogVGhlIGxlbmd0aCBvZiB0aGUgTm9uY2UgT3B0aW9uIChpbiBvY3RldHMpLA0K PiAgICAgICBpbmNsdWRpbmcgdGhlIDQgb2N0ZXQgZml4ZWQgaGVhZGVyIGFuZCB0aGUgdmFyaWFi bGUgbGVuZ3RoIG9mIHRoZQ0KPiAgICAgICBhdXRoZW50aWNhdGlvbiBkYXRhLg0KPiANCj4gQ01Q OiBUaGUgZm9ybWF0IG9mIHRoZSBmaWd1cmUgZG9lcyBub3Qgc2hvdyBhbnkgQXV0aGVudGljYXRp b24gRGF0YS4gSXMgdGhpcw0KPiBPcHRpb24tTGVuZ3RoIGFsd2F5cyA0Pw0KDQpJdCB3YXMgYSBj dXQgYW5kIHBhc3RlIG1pc3Rha2UsIGNvcnJlY3RlZCBvcHRpb24gbGVuZ3RoIGZpZWxkIGZvciBh bGwgb3B0aW9ucy4NClRoYW5rcyBmb3IgY2F0Y2hpbmcgaXQuDQoNCj4gDQo+IDUuNC4gIEF1dGhl bnRpY2F0aW9uIFRhZyBPcHRpb24gZm9yIENvbW1vbiBQQ1AgTWVzc2FnZXMNCj4gDQo+ICAgICAg IE9wdGlvbi1MZW5ndGg6IFRoZSBsZW5ndGggb2YgdGhlIEF1dGhlbnRpY2F0aW9uIFRhZyBPcHRp b24gZm9yDQo+ICAgICAgIENvbW1vbiBQQ1AgKGluIG9jdGV0cyksIGluY2x1ZGluZyB0aGUgMTIg b2N0ZXQgZml4ZWQgaGVhZGVyIGFuZA0KPiAgICAgICB0aGUgdmFyaWFibGUgbGVuZ3RoIG9mIHRo ZSBhdXRoZW50aWNhdGlvbiBkYXRhLg0KPiANCj4gQ01QOiBJcyBpdCBuZWNlc3NhcnkgdG8gY2xh cmlmeSB0aGF0IHdoZW4gdGhlIEF1dGggRGF0YSBpcyBwYWRkZWQsIHRoZSBsZW5ndGgNCj4gc3Rp bGwgcmVmbGVjdHMgdGhlIHVucGFkZGVkIGRhdGEgbGVuZ3RoPw0KDQpObywgaXQgaXMgYWxyZWFk eSBkaXNjdXNzZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjg4NyNzZWN0aW9u LTcuMyANCg0KPiANCj4gNS41LiAgQXV0aGVudGljYXRpb24gVGFnIE9wdGlvbiBmb3IgUEEgTWVz c2FnZXMNCj4gDQo+ICAgICAgIE9wdGlvbi1MZW5ndGg6IFRoZSBsZW5ndGggb2YgdGhlIEF1dGhl bnRpY2F0aW9uIFRhZyBPcHRpb24gZm9yIFBDUA0KPiAgICAgICBBdXRoIChpbiBvY3RldCksIGlu Y2x1ZGluZyB0aGUgMTIgb2N0ZXQgZml4ZWQgaGVhZGVyIGFuZCB0aGUNCj4gICAgICAgdmFyaWFi bGUgbGVuZ3RoIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBkYXRhLg0KPiANCj4gQ01QOiBUaGlzIG9u ZSBzZWVtcyB0byBvbmx5IGluY2x1ZGUgNCAoYW5kIG5vdCAxMikgb2N0ZXRzIG9mIGZpeGVkIGhl YWRlci4NCg0KWWVzLCBjb3JyZWN0ZWQuDQoNCj4gDQo+IDUuNi4gIEVBUCBQYXlsb2FkIE9wdGlv bg0KPiANCj4gICAgICAgT3B0aW9uLUxlbmd0aDogVGhlIGxlbmd0aCBvZiB0aGUgRUFQIFBheWxv YWQgT3B0aW9uIChpbiBvY3RldHMpLA0KPiAgICAgICBpbmNsdWRpbmcgdGhlIDQgb2N0ZXQgZml4 ZWQgaGVhZGVyIGFuZCB0aGUgdmFyaWFibGUgbGVuZ3RoIG9mIHRoZQ0KPiAgICAgICBFQVAgbWVz c2FnZS4NCj4gDQo+IENNUDogV2hhdCBpcyB0aGUgZml4ZWQgaGVhZGVyIGluIHRoaXMgb25lPw0K DQpUaGVyZSBpcyBubyBmaXhlZCBoZWFkZXIsIGNvcnJlY3RlZCB0ZXh0Lg0KDQo+IA0KPiA1Ljcu ICBQUkYgT3B0aW9uDQo+IA0KPiAgICBPcHRpb24tTGVuZ3RoOiBUaGUgbGVuZ3RoIG9mIHRoZSBQ UkYgT3B0aW9uIChpbiBvY3RldHMpLCBpbmNsdWRpbmcNCj4gICAgdGhlIDQgb2N0ZXQgZml4ZWQg aGVhZGVyIGFuZCB0aGUgdmFyaWFibGUgbGVuZ3RoIG9mIHRoZSBFQVAgbWVzc2FnZS4NCj4gDQo+ IENNUDogV2hhdCBpcyB0aGUgdmFyaWFibGUgbGVuZ3RoIGluIHRoaXMgb25lPyBJcyBpdCBhbHdh eXMgND8NCg0KWWVzLCBpdCBpcyBhbHdheXMgNC4NCg0KPiANCj4gNy4gIElBTkEgQ29uc2lkZXJh dGlvbnMNCj4gDQo+ICAgIE9wY29kZXMgaXMgbWFpbnRhaW5lZCBpbiBodHRwOi8vd3d3LmlhbmEu b3JnLyBhc3NpZ25tZW50cy9wY3AtDQo+ICAgIHBhcmFtZXRlcnMpOg0KPiANCj4gQ01QOiBUaGUg VVJMcyBwb2ludGluZyB0byBwY3AtcGFyYW1ldGVycyBhcmUgYnJva2VuLg0KDQpGaXhlZC4NCg0K PiANCj4gICAgVEJBIEF1dGhlbnRpY2F0aW9uIE9wY29kZS4NCj4gDQo+IENNUDogQW4gZWRpdG9y aWFsIHN1Z2dlc3Rpb24sIGl0IGhlbHAgd2l0aCByZWFkYWJpbGl0eSBvZiB0aGlzIHNlY3Rpb24g dG8gaW5kZW50DQo+IHRoZSBhY3R1YWwgYXNzaWdubWVudHMgZm9yIFBDUCBPcGNvZGUgYW5kIFBD UCBPcHRpb24gQ29kZXMsIHN1Y2ggYXMgaXQgaXMNCj4gZG9uZSB3aXRoIFBDUCByZXN1bHQgY29k ZXM6DQo+IA0KPiAgICAgICBUQkEgSU5JVElBVElPTjogVGhlIGNsaWVudCBpbmRpY2F0aW9uIHRv IHRoZSBzZXJ2ZXIgZm9yDQo+ICAgICAgIGF1dGhlbnRpY2F0aW9uLg0KPiANCj4gDQo+ICAgIE1h eGltdW0gb2NjdXJlbmNlczogIDEuDQo+IA0KPiBDTVA6IHMvb2NjdXJlbmNlcy9vY2N1cnJlbmNl cy9nDQoNClJlcGxhY2VkLg0KDQo+IA0KPiBSZWZlcmVuY2VzOg0KPiANCj4gQ01QOiBJZG5pdHMg ZmluZHMgdGhlc2UgdHdvOg0KPiANCj4gICAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNl IHRvIGFuIEluZm9ybWF0aW9uYWwgUkZDOiBSRkMgNTI4MQ0KDQpZZXMsIGl0IHdhcyBpbnRlbnRp b25hbC4gUGxlYXNlIHJlZmVyIHRvIHRoZSBleHBsYW5hdGlvbiBnaXZlbiBieSBEYXZlIFRoYWxl ciBjby1hdXRob3Igb2YgUENQIFdHDQppbiB0aGUgU2hlcGFyZCB3cml0ZS11cA0KDQo8c25pcD4N Cg0KKDE1KSBBcmUgdGhlcmUgZG93bndhcmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgKHNlZSBSRkMg Mzk2Nyk/DQoNCiAgICBZZXMuICBUaGUgV0cgYWdyZWVkIHRoYXQgaGF2aW5nIGEgbWFuZGF0b3J5 LXRvLWltcGxlbWVudCBFQVAgbWV0aG9kDQogICAgd2FzIHJlcXVpcmVkIGZvciBpbnRlcm9wZXJh YmlsaXR5LiAgVGhlIFdHIHN1cnZleWVkIEVBUCBpbXBsZW1lbnRlcnMvZXhwZXJ0cw0KICAgIGFz IG5vdGVkIGluIFE1IGFib3ZlIGFuZCBmb3VuZCB0aGF0IHRoZXJlIGlzIG5vIHN0YW5kYXJkcyB0 cmFjayBFQVAgbWV0aG9kIHRoYXQNCiAgICBpcyBhdmFpbGFibGUgaW4gYWxsIHRoZSByZWxldmFu dCBFQVAgaW1wbGVtZW50YXRpb25zLiAgQXMgc3VjaCwgdGhlIEVBUCBleHBlcnQNCiAgICByZXZp ZXdlcnMgYWR2aWNlIHdhcyBmb2xsb3dlZCwgd2hpY2ggd2FzIHRvIHJlcXVpcmUgUkZDIDUyODEg KHdpZGVseSBpbXBsZW1lbnRlZA0KICAgIGJ1dCBvbmx5IGFuIEluZm9ybWF0aW9uYWwgUkZDKSB3 aGlsZSBtYWtpbmcgdGhlIG5ldyBSRkMgNzE3MCAocHJvcG9zZWQNCiAgICBzdGFuZGFyZCwgYnV0 IG5vdCBpbXBsZW1lbnRlZCkgYSBTSE9VTEQuICBUaGUgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8N CiAgICByZXF1aXJlIFJGQyA3MTcwLCB3aGljaCB0aGUgZmVlZGJhY2sgaW5kaWNhdGVkIHdvdWxk IGJsb2NrIGRlcGxveW1lbnQNCiAgICBvZiB0aGlzIGRyYWZ0IGZvciBzb21lIHRpbWUgdG8gY29t ZS4gIEhhdmluZyBzZWN1cml0eSBmb3IgUENQIHNvb25lciB0aGFuDQogICAgbGF0ZXIgd2FzIGRl dGVybWluZWQgdG8gYmUgaW1wb3J0YW50LCBhbmQgc28gdGhlIFdHIHdvdWxkIGxpa2UgdG8gcmVx dWVzdA0KICAgIGFwcHJvdmFsIGZvciB0aGlzIGRvd253YXJkIHJlZmVyZW5jZS4NCg0KPC9zbmlw Pg0KDQo+IA0KPiAgICoqIE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6IFJGQyA1OTk2IChP YnNvbGV0ZWQgYnkgUkZDIDcyOTYpDQoNCkZpeGVkLg0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IA0K PiBUaGFua3MhDQo+IA0KPiDigJQgQ2FybG9zLg0KPiANCg0K From nobody Tue Jun 9 09:05:07 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE1F1A896C for ; Tue, 9 Jun 2015 09:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS-eukS5C01r for ; Tue, 9 Jun 2015 09:05:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3130B1A1A06 for ; Tue, 9 Jun 2015 09:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63024; q=dns/txt; s=iport; t=1433865902; x=1435075502; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hPm20EN8Kj0bJPA1jxHpCrIesgGvSVvLmgdAH2yVlv8=; b=EkFdwJTft2FYBDAnWtF3imLljs6gt3DoO8gcEJKW9+oM7XVUJZIpvL56 3GjFydIVtcjH2rB62+Tn1Pyhf/xug36FkzrMKHEvwJ3fllXAMEgWQUuMY 4jgpi/1azsW3T1iVZAocF+h8phR++yryiXNOUbphw2jCIFjdk03rsti4c 8=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CdBwCTDXdV/5ldJa1cgkVLVFENBoMYunE8ghSFeQKBR0wBAQEBAQGBC4QiAQEBAQIBI0gOBQcEAgEIEQQBAQEgAQkCAjIdCAIEDgUJBYgYCA2scKQkAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhDtLBwYDgl8vgRYFkG+CT4IYgUlhhm6BMECDO5JAERODeG8BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,581,1427760000"; d="asc'?scan'208,217";a="2060226" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jun 2015 16:05:00 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t59G50qE005488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jun 2015 16:05:00 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 9 Jun 2015 11:05:00 -0500 From: "Carlos Pignataro (cpignata)" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: Int-Dir Review of draft-ietf-pcp-authentication-09 Thread-Index: AQHQogEu9zCKc4FkUk21nfO30UKKbJ2kGQ6AgACS04A= Date: Tue, 9 Jun 2015 16:04:59 +0000 Message-ID: <16EA87F4-B53D-4195-B66D-25E599B6917F@cisco.com> References: <913383AAA69FF945B8F946018B75898A47866B6A@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A47866B6A@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.55.174] Content-Type: multipart/signed; boundary="Apple-Mail=_0F60259C-245B-4F19-A7C0-61711927AF80"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "int-ads@tools.ietf.org" , "pcp-chairs@tools.ietf.org" , "draft-ietf-pcp-authentication@tools.ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] Int-Dir Review of draft-ietf-pcp-authentication-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:05:06 -0000 --Apple-Mail=_0F60259C-245B-4F19-A7C0-61711927AF80 Content-Type: multipart/alternative; boundary="Apple-Mail=_B36EE6DA-3BF5-41BE-A3FB-23D20BA6E941" --Apple-Mail=_B36EE6DA-3BF5-41BE-A3FB-23D20BA6E941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Tiru! > On Jun 9, 2015, at 3:19 AM, Tirumaleswar Reddy (tireddy) = wrote: >=20 > Hi Carlos, >=20 > Thanks for the review. Please see inline >=20 >> -----Original Message----- >> From: Carlos Pignataro (cpignata) >> Sent: Monday, June 08, 2015 9:09 PM >> To: int-dir@ietf.org; int-ads@tools.ietf.org >> Cc: draft-ietf-pcp-authentication@tools.ietf.org; = pcp-chairs@tools.ietf.org >> Subject: Int-Dir Review of draft-ietf-pcp-authentication-09 >>=20 >> Hi, >>=20 >> I am an assigned INT directorate reviewer for = draft-ietf-pcp-authentication-09. >>=20 >> These comments were written primarily for the benefit of the Internet = Area >> Directors. Document editors and shepherd(s) should treat these = comments just >> like they would treat comments from any other IETF contributors and = resolve >> them along with any other Last Call comments that have been received. = For >> more details on the INT Directorate, see >> http://www.ietf.org/iesg/directorate.html. >>=20 >> Summary: >>=20 >> This document describes an EAP-based Authentication mechanism for the = Port >> Control Protocol (PCP), meeting the security requirements of the = Advanced >> Threat Model in the base PCP specification. Its intended status is = Standards >> Track. >>=20 >> This is a very well written document. I only found minor issues = (e.g., option- >> lengths), editorials and nits. >>=20 >> Major Issues: >>=20 >> None. >>=20 >> Minor Issues, Nits, Editorials: >>=20 >> I hope you find these useful: >>=20 >> General: >>=20 >> CMP: There are variations of =E2=80=9Csession ID=E2=80=9D vs. = =E2=80=9CSession-ID=E2=80=9D vs. =E2=80=9CSession_ID=E2=80=9D and >> others. Same with =E2=80=9Copcode=E2=80=9D vs. =E2=80=9COpcode=E2=80=9D= and others, which should be >> normalized. >=20 > Fixed. >=20 >>=20 >> 1. Introduction >>=20 >> This document proposes a PCP security >> extension which enables PCP servers to authenticate their clients >> with Extensible Authentication Protocol (EAP). >>=20 >> CMP: s/which/that/ >=20 > Fixed. >=20 >>=20 >> CMP: Does this document =E2=80=9Cproposes=E2=80=9D or =E2=80=9Cdescribe= s=E2=80=9D / =E2=80=9Cdefines"? >=20 > "defines" seems to fits better. >=20 >>=20 >> 2. Terminology >>=20 >> PCP Client: A PCP software instance which is responsible for = issuing >>=20 >> CMP: s/which/that/ [there are a couple more instances of this] >=20 > Fixed. >=20 >>=20 >> 5.X. For all the 5.X sections, starting from 5.3: >>=20 >> CMP: Reserved =E2=80=94 could we specify the treatment of Reserved = bits (e.g., MBZ)? >> Like =E2=80=9CReserved: MUST be zero on transmission and MUST be = ignored on >> reception." >=20 > Yes, updated. >=20 >>=20 >> CMP: What follows is some potential issues with Option-Lengths. I = might be >> missing something. >>=20 >> 5.3. Nonce Option >>=20 >> Option-Length: The length of the Nonce Option (in octets), >> including the 4 octet fixed header and the variable length of = the >> authentication data. >>=20 >> CMP: The format of the figure does not show any Authentication Data. = Is this >> Option-Length always 4? >=20 > It was a cut and paste mistake, corrected option length field for all = options. > Thanks for catching it. >=20 >>=20 >> 5.4. Authentication Tag Option for Common PCP Messages >>=20 >> Option-Length: The length of the Authentication Tag Option for >> Common PCP (in octets), including the 12 octet fixed header and >> the variable length of the authentication data. >>=20 >> CMP: Is it necessary to clarify that when the Auth Data is padded, = the length >> still reflects the unpadded data length? >=20 > No, it is already discussed in = http://tools.ietf.org/html/rfc6887#section-7.3 = >=20 >>=20 >> 5.5. Authentication Tag Option for PA Messages >>=20 >> Option-Length: The length of the Authentication Tag Option for = PCP >> Auth (in octet), including the 12 octet fixed header and the >> variable length of the authentication data. >>=20 >> CMP: This one seems to only include 4 (and not 12) octets of fixed = header. >=20 > Yes, corrected. >=20 >>=20 >> 5.6. EAP Payload Option >>=20 >> Option-Length: The length of the EAP Payload Option (in octets), >> including the 4 octet fixed header and the variable length of = the >> EAP message. >>=20 >> CMP: What is the fixed header in this one? >=20 > There is no fixed header, corrected text. >=20 >>=20 >> 5.7. PRF Option >>=20 >> Option-Length: The length of the PRF Option (in octets), including >> the 4 octet fixed header and the variable length of the EAP = message. >>=20 >> CMP: What is the variable length in this one? Is it always 4? >=20 > Yes, it is always 4. >=20 >>=20 >> 7. IANA Considerations >>=20 >> Opcodes is maintained in http://www.iana.org/ = assignments/pcp- >> parameters): >>=20 >> CMP: The URLs pointing to pcp-parameters are broken. >=20 > Fixed. >=20 >>=20 >> TBA Authentication Opcode. >>=20 >> CMP: An editorial suggestion, it help with readability of this = section to indent >> the actual assignments for PCP Opcode and PCP Option Codes, such as = it is >> done with PCP result codes: >>=20 >> TBA INITIATION: The client indication to the server for >> authentication. >>=20 >>=20 >> Maximum occurences: 1. >>=20 >> CMP: s/occurences/occurrences/g >=20 > Replaced. >=20 >>=20 >> References: >>=20 >> CMP: Idnits finds these two: >>=20 >> ** Downref: Normative reference to an Informational RFC: RFC 5281 >=20 > Yes, it was intentional. Please refer to the explanation given by Dave = Thaler co-author of PCP WG > in the Shepard write-up >=20 > >=20 > (15) Are there downward normative references (see RFC 3967)? >=20 > Yes. The WG agreed that having a mandatory-to-implement EAP method > was required for interoperability. The WG surveyed EAP = implementers/experts > as noted in Q5 above and found that there is no standards track EAP = method that > is available in all the relevant EAP implementations. As such, the = EAP expert > reviewers advice was followed, which was to require RFC 5281 = (widely implemented > but only an Informational RFC) while making the new RFC 7170 = (proposed > standard, but not implemented) a SHOULD. The alternative would be = to > require RFC 7170, which the feedback indicated would block = deployment > of this draft for some time to come. Having security for PCP = sooner than > later was determined to be important, and so the WG would like to = request > approval for this downward reference. >=20 > >=20 >>=20 >> ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) >=20 > Fixed. >=20 > Cheers, > -Tiru >=20 >>=20 >> Thanks! >>=20 >> =E2=80=94 Carlos. --Apple-Mail=_B36EE6DA-3BF5-41BE-A3FB-23D20BA6E941 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Tiru!


On Jun 9, 2015, at 3:19 AM, Tirumaleswar Reddy (tireddy) = <tireddy@cisco.com> wrote:

Hi Carlos,

Thanks for the review. Please see = inline

-----Original Message-----
From: Carlos = Pignataro (cpignata)
Sent: Monday, June 08, 2015 9:09 = PM
To: int-dir@ietf.org; int-ads@tools.ietf.org
Cc: draft-ietf-pcp-authentication@tools.ietf.org; pcp-chairs@tools.ietf.org
Subject: Int-Dir = Review of draft-ietf-pcp-authentication-09

Hi,

I am an assigned INT = directorate reviewer for draft-ietf-pcp-authentication-09.

These comments were written primarily for the = benefit of the Internet Area
Directors. Document editors = and shepherd(s) should treat these comments just
like they = would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been = received. For
more details on the INT Directorate, see
http://www.ietf.org/iesg/directorate.html.

Summary:

This = document describes an EAP-based Authentication mechanism for the Port
Control Protocol (PCP), meeting the security requirements of = the Advanced
Threat Model in the base PCP specification. = Its intended status is Standards
Track.

This is a very well written document. I only found minor = issues (e.g., option-
lengths), editorials and nits.

Major Issues:

None.

Minor Issues, Nits, = Editorials:

I hope you find these = useful:

General:

CMP: There are variations of =E2=80=9Csession ID=E2=80=9D vs. = =E2=80=9CSession-ID=E2=80=9D vs. =E2=80=9CSession_ID=E2=80=9D and
others. Same with =E2=80=9Copcode=E2=80=9D vs. =E2=80=9COpcode=E2= =80=9D and others, which should be
normalized.

Fixed.


1. =  Introduction

  This = document proposes a PCP security
  extension = which enables PCP servers to authenticate their clients
  with Extensible Authentication Protocol (EAP).

CMP: s/which/that/

Fixed.


CMP: = Does this document =E2=80=9Cproposes=E2=80=9D or =E2=80=9Cdescribes=E2=80=9D= / =E2=80=9Cdefines"?

"defines" seems to fits better.


2. =  Terminology

  PCP Client: A = PCP software instance which is responsible for issuing

CMP: s/which/that/ [there are a couple more instances of = this]

Fixed.


5.X. =  For all the 5.X sections, starting from 5.3:

CMP: Reserved =E2=80=94 could we specify the treatment of = Reserved bits (e.g., MBZ)?
Like =E2=80=9CReserved: MUST be = zero on transmission and MUST be ignored on
reception."

Yes, updated.


CMP: = What follows is some potential issues with Option-Lengths. I might be
missing something.

5.3. =  Nonce Option

     Option-Length: The length of = the Nonce Option (in octets),
     including the 4 octet fixed = header and the variable length of the
     authentication data.

CMP: The format of the figure does not show = any Authentication Data. Is this
Option-Length always = 4?

It was a cut and paste = mistake, corrected option length field for all options.
Thanks for catching it.


5.4. =  Authentication Tag Option for Common PCP Messages

     Option-Length: The length of = the Authentication Tag Option for
     Common PCP (in octets), = including the 12 octet fixed header and
     the variable length of the = authentication data.

CMP: Is it necessary = to clarify that when the Auth Data is padded, the length
still reflects the unpadded data length?

No, it is already = discussed in http://tools.ietf.org/html/rfc6887#section-7.3 


5.5. =  Authentication Tag Option for PA Messages

     Option-Length: The length of = the Authentication Tag Option for PCP
     Auth (in octet), including the = 12 octet fixed header and the
     variable length of the = authentication data.

CMP: This one seems to = only include 4 (and not 12) octets of fixed header.

Yes, corrected.


5.6. =  EAP Payload Option

     Option-Length: The length of = the EAP Payload Option (in octets),
     including the 4 octet fixed = header and the variable length of the
     EAP message.

CMP: What is the fixed header in this one?

There is no fixed header, = corrected text.


5.7.  PRF Option

  Option-Length: The length of the PRF Option (in = octets), including
  the 4 octet fixed header = and the variable length of the EAP message.

CMP: What is the variable length in this one? Is it always = 4?

Yes, it is always = 4.


7.  IANA Considerations

  Opcodes is maintained in http://www.iana.org/ assignments/pcp-
  parameters):

CMP: = The URLs pointing to pcp-parameters are broken.

Fixed.


  TBA Authentication Opcode.

CMP: An editorial suggestion, it help with readability of = this section to indent
the actual assignments for PCP = Opcode and PCP Option Codes, such as it is
done with PCP = result codes:

     TBA INITIATION: The client = indication to the server for
     authentication.

  Maximum occurences:  1.

CMP: s/occurences/occurrences/g

Replaced.


References:

CMP: Idnits finds = these two:

 ** Downref: Normative = reference to an Informational RFC: RFC 5281
Yes, it was intentional. Please refer to the = explanation given by Dave Thaler co-author of PCP WG
in the Shepard write-up

<snip>

(15) Are there downward normative references = (see RFC 3967)?

   Yes. =  The WG agreed that having a mandatory-to-implement EAP = method
   was = required for interoperability.  The WG surveyed EAP = implementers/experts
   as noted = in Q5 above and found that there is no standards track EAP method = that
   is = available in all the relevant EAP implementations.  As such, the = EAP expert
   reviewers = advice was followed, which was to require RFC 5281 (widely = implemented
   but only = an Informational RFC) while making the new RFC 7170 (proposed
   standard, but not implemented) = a SHOULD.  The alternative would be to
   require RFC 7170, which the = feedback indicated would block deployment
   of this draft for some time to = come.  Having security for PCP sooner than
   later was determined to be = important, and so the WG would like to request
   approval for this downward = reference.

</snip>


 ** = Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296)

Fixed.

Cheers,
-Tiru


Thanks!

=E2=80= =94 Carlos.

= --Apple-Mail=_B36EE6DA-3BF5-41BE-A3FB-23D20BA6E941-- --Apple-Mail=_0F60259C-245B-4F19-A7C0-61711927AF80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVdw6rAAoJEIXgpQGOZny9CbEQAKHGdVE++osuCZBM9yPf4jBR t7gMMqv8vXATw7n8O2mgUB1N1EajIS0fa1R+cQyzvnUFWLrqK7FqiSdJoJRy2aJ+ 7yN4CoVzyhEZpwAlvSchDA0Qovi7EJ9gXLLNYTK5N0C712mHeHLz2e8+cKhbyQpJ oY1uN2wSU9v2ko+BUClG+vGmwB7u9g+eTnJnMQML7R5ZVs1UyXu2duj+O1TXaRXj 7I261tSOA+kfom5d6sJIozqztqwbbE4/ATrY9GCNk2xzDlAglNxYJyc/Yaaz4f6o +VLUz0xzx4HgKCb6PojofzL1iyiv8T8WXmXCbNoxtNcAfFvLH1e0qwFBId4r54r7 QnK7p5PpDe1WVoz15UPy1nQaFe7LBSvN4mvd8uyHw1JXvfFKuQ64em+vS2+wf0SL +XqNZDtdYvFdJ3sRGGT2aLOpAl5ZPYCwT2O8GebUTNOJ3W9MQGL3+yLXZveRP6KY 94HtKPpWqYZgvpEH3OMjL1orLo1LBpTvp6uygEHsAb0oGe1BVRJ7KDehlZYEXH6B TrVEWQEkV3/peJoTFbwKhkc9dXViu5uSl2Et7g94vqUmvE1Jc3CNr9DnzV5rcI5v kg4RGLgw51fSHECiFpn+tKvJF6k9YLoly3DaJUo155V9HZu77cS6j11KxDPXIdGo FsbhysU2FG2KmSjseXd5 =L3lK -----END PGP SIGNATURE----- --Apple-Mail=_0F60259C-245B-4F19-A7C0-61711927AF80-- From nobody Wed Jun 10 12:13:24 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDCD1A8750; Wed, 10 Jun 2015 12:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEhRi0ESZ8CC; Wed, 10 Jun 2015 12:10:51 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B441A8739; Wed, 10 Jun 2015 12:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15749; q=dns/txt; s=iport; t=1433963447; x=1435173047; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=L2tK5KD7Vr/CG3CZ8NPrND6JaK26Z8u1vcRBK819d38=; b=O6onw3gfP98fJvmZtSfhDopo4pyr/ZOVZW4xllPY37+tEfRtgdXdZ7aZ Jix66yA/9j+MLg/nAjC5FI0Vg8uX430O1EbawSBT32E1tfSE5RQnStAdC QI01x0hclmAG5aC8bm+c4j7f9t+NE7oq/WofBTlTXQ/i8HU2gJF/UcMcR w=; X-IronPort-AV: E=Sophos;i="5.13,588,1427760000"; d="scan'208";a="158098004" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 10 Jun 2015 19:10:45 +0000 Received: from [161.44.70.106] ([161.44.70.106]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5AJAgOL014065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Jun 2015 19:10:43 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kim Kinnear In-Reply-To: <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> Date: Wed, 10 Jun 2015 15:10:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9AF39E1E-E858-450E-9925-27557C737FDD@cisco.com> References: <5564C840.2070908@innovationslab.net> <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> To: Brian Haberman , Ted Lemon X-Mailer: Apple Mail (2.1878.6) X-Authenticated-User: kkinnear Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 12:13:22 -0700 Cc: draft-ietf-dhc-dhcpv6-active-leasequery@ietf.org, int-ads@ietf.org, "" , "dhcwg@ietf.org WG" , Kim Kinnear , Sheng Jiang Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:10:54 -0000 Brian, Ted, We have published new versions of both of the DHCPv6 Active Leasequery draft as well as the DHCPv4 Active Leasequery draft (since they are essentially identical in all but the specifics of the v4/v6 data). = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/ = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/ I believe that we have covered all of the issues raised by Ted. After submission, I did notice two things that we need to change: 1. Both drafts have a sentence: "Alternatively, both requests could be issued over a single connection." which we didn't catch when we removed the capability to handle multiple simultaneous requests on a single connection. This sentence will have to be removed. 2. The DHCPv4 draft still has a sentence stating that the requestor can choose insecure or secure mode: "Alternatively, the server MAY allow the client to select the mode through transmission of a DHCPTLS to select the secure mode or transmission of an Active Leasequery request to select the insecure mode." This sentence also needs to be removed. Both drafts force the server to decide whether or not TLS is required. While we could republish both drafts immediately, it seemed prudent to let Ted review the changes to see if we have successfully responded to his concerns. We will certainly have to republish both drafts, if only to fix these problems. One more question. Ted said (and we are fine with this): > I think the most useful mode of operation here is the one you are = leaving out. Nobody wants to pay a CA to sign certs for all their = infrastructure servers, but having a local CA and just installing the = local CA as a trusted root would work fine for this application; indeed = you probably don't want to configure leasequery partners to accept the = standard set of CA roots.=20 We have put words in the draft(s) about certificates (here is one = example): > During the TLS handshake, the requestor MUST verify the DHCPv4 > server's digital certificates. Ted, do you feel that we need to be more explicit regarding the approach that you advocated regarding certificates, above, to allow that as a reasonable option? If so, any suggestions for the words that we might use? Thanks! I have included the DHCWG mailing list on this email to ensure that the progress these documents are making continues to be visible to the = entire DHC WG. =20 Regards -- Kim On May 28, 2015, at 1:52 PM, Kim Kinnear wrote: >=20 > Brian, Ted, >=20 > Here are our comments regarding Ted's review, inline below... >=20 > I believe that we need a new revision of the draft to include these > changes (and the corresponding DHCPv4 draft, which has almost the same > words in the same places). >=20 > That said, I don't believe that any of this requires a new WGLC, as we > aren't really changing the intent of what we were trying to say in any > really significant way. >=20 > The only substantive change is removing the multiple messages per > connection, which *is* a change, but isn't a big deal in my view. I > say this in part because nobody had any comments about that as we were > working this with the DHC WG. I think the only person who cared was > Bernie, and I've already checked with him and he's ok with it. >=20 > But that's just my opinion... >=20 > Regards -- Kim >=20 >=20 > On May 26, 2015, at 3:23 PM, Brian Haberman = wrote: >=20 >> Ted, >> Thanks for the review! >>=20 >> Authors, >> I would like you to respond to these so that we can determine the >> best way forward. >>=20 >> Regards, >> Brian >>=20 >>=20 >> On 5/20/15 3:50 PM, Ted Lemon wrote: >>> I am an assigned INT directorate reviewer for >>> draft-ietf-dhc-dhcpv6-active-leasequery-02.txt. These comments were >>> written primarily for the benefit of the Internet Area Directors. >>> Document editors and shepherd(s) should treat these comments just as >>> they would treat comments from any other IETF contributors and >>> resolve them along with any other Last Call comments that have been >>> received. For more details on the INT Directorate, see: >>> http://www.ietf.org/iesg/directorate.html >>>=20 >>> Major issues: >>>=20 >>> The specification of TLS negotiation in section 8.2 allows for an >>> MiTM attack: the man in the middle simply has to respond negatively >>> to the STARTTLS message, and the communication will occur in the >>> clear. =20 >=20 > This was not what we were trying to say in the document. >=20 > Ultimately, we expect that either the client or the server can > be configured in one of three distinct ways regarding TLS: >=20 > 1. Require TLS for all communication with the partner. >=20 > 2. Support TLS if requested to do so by the partner, but allow > communications in the clear if TLS is not requested by the > partner. >=20 > 3. Not support TLS at all. If the partner requires TLS, it > won't be communicating with us. Period. >=20 > The intent in section 8.2 for the client is that if the DHCP > server doesn't want to support TLS for this connection, then > the client will respond based on how it is configured. If it > is configured as in #1, above, then it will not communicate > with this server. If it is configured as in #2 then it will > continue with communications in the clear. If the client was > configured as in #3, it would not have sent the STARTTLS > message. >=20 > We will add words in section 8.2 to make that clearer. >=20 >>> This could be addressed by requiring that if the DHCP server >>> is configured to use TLS, it will not allow a connection to proceed >>> without successfully completing the TLS handshake. >=20 > That is what we were trying to say, though we have a slightly > nuanced interpretation of "use TLS". Again, referring to the > three configuration possibilities regarding TLS above: >=20 > 1. Require TLS for all communication with the partner. >=20 > 2. Support TLS if requested to do so by the partner, but allow > communications in the clear if TLS is not requested by the > partner. >=20 > 3. Not support TLS at all. If the partner requires TLS, it > won't be communicating with us. Period. >=20 > If the server is configured as in #1, the server will do > exactly what Ted is requesting: the server will not allow the > connection to proceed without completing the TLS handshake. >=20 >>> In this case, an >>> MiTM attack would simply prevent the connection from completing. I >>> guess this change would actually be made in section 9.1: if the >>> requestor doesn't request TLS, and the server is configured to >>> require it, then it will drop the connection. >=20 > Yes, we will put some words in section 9.1 to make these > three possibilities (and their implications) hopefully > much clearer. >>>=20 >>> I don't think support for STARTTLS should be optional, hence = handling >>> cases where it is not supported should be unnecessary. >=20 > We never intended that the STARTTLS message support itself > was to be optional, but I can see where it might look like > it was. We will fix that. >>>=20 >>> Section 8.2 and 9.1 also do not talk about TLS cert validation, so = it >>> amounts to opportunistic encryption, and is still subject to MiTM >>> attacks since the attacker can simply use a different key than the >>> DHCP server. To enable TLS support to actually provide security, = it >>> would be necessary for the requestor to use a client cert that the >>> server validates, and for the server to use a cert that the = requestor >>> validates. If the requestor's cert doesn't validate, the = connection >>> is dropped; if the server's cert doesn't validate, the requestor >>> drops the connection. >=20 > Yes, and we left implicit our intent here, which was probably > a mistake.=20 >=20 > We expect that a client or a server can be configured (or > implemented directly) in one of two modes regarding TLS > connections: >=20 > a) Require TLS certificate validation (ensuring that you > are talking to the partner to whom you believe you are > talking to). >=20 > b) Do not require TLS certificate validation (ensuring only > that your conversation cannot be eavesdropped on, but not > ensuring that you are talking to the correct partner). >=20 > We will make explicit these two possibilities, and describe > the downsides of (b). =20 >=20 >>>=20 >>> In section 8.4, if the connection is terminated while an active >>> leasequery is in the catch-up state, I don't think the current >>> recommendation for sending OPTION_LQ_BASE_TIME is adequate. In = this >>> case the requestor will likely have to retry from the same starting >>> time it had used previously. >=20 > Yes, we completely agree! I'm delighted that you got it! >=20 > Unfortunately, We think we said this explicitly at least > three times, including: >>=20 >> Prior to the completion of the >> catch-up phase, if the connection should go away or if the = requestor >> receives a LEASEQUERY-DONE message, then when it reconnects it MUST >> use the base-time value from the previous connection and not any >> base-time value received from the recently closed connection. >=20 > and: >=20 >> Therefore, until >> the catch-up phase is complete, the latest base-time value received >> from a DHCPv6 server processing an Active Leasequery request cannot >> be reset from the incoming messages (and used in a subsequent = Active >> Leasequery's query-start-time option), because to do so would >> compromise the ability to recover lost information if the Active >> Leasequery were to terminate prior to the completion of the = catch-up >> phase. >=20 > and: >=20 >> The updates sent by the DHCPv6 server during the catch-up phase are >> not in the order that the lease state data was updated. Therefore, >> the OPTION_LQ_BASE_TIME option from messages during this phase MUST >> NOT be saved and used to compute the subsequent ACTIVELEASEQUERY >> message's OPTION_LQ_START_TIME option. >=20 >=20 > so ... either I don't understand your concern, or we are=20 > really not able to communicate this information in a way > that makes any sense. >=20 >>>=20 >>> Minor issues: >>>=20 >>> Section 2, definition for "Absolute Time", is the 32-bit quantity >>> signed or unsigned? > =09 > Good catch, unsigned is the DHCPv6 approach, which is from=20 > RFC 3315: >=20 >> The time value is the time that the DUID is >> generated represented in seconds since midnight (UTC), January = 1, >> 2000, modulo 2^32. >=20 >=20 >>> Definition for "binding change/update", aren't "DHCPv6 binding = state" >>> and "data stored on the DHCPv6 server related to binding" synonyms? >>> If so, perhaps what you really need here is an additional definition >>> for "DHCPv6 binding state" which is "data stored on the DHCPv6 = server >>> relating to binding." I don't think this is a big deal, but might >>> be a nice edit for clarity. >=20 > Sure, no problem. >>>=20 >>> Similarly, why not split "catch-up information" and "catch-up phase" >>> into two separate definitions? >=20 > Ok, sure. >>>=20 >>> Last paragraph of section 3 says "The messages sent by the server in >>> response to an Active Leasequery request SHOULD be identical to the >>> messages sent by the server to a Bulk Leasequery request regarding >>> the way the data is encoded into the Active Leasequery responses. = In >>> addition, the actions taken by the Active Leasequery requestor to >>> interpret the responses to an Active Leasequery request SHOULD be >>> identical to the way that the requestor interprets the responses to = a >>> Bulk Leasequery request." What is the purpose of the normative >>> SHOULDs here? Are there exceptional cases where this normative >>> advice would not be followed? Is this text really intended to be >>> normative? >=20 > Somehow I'm always kind of iffy when it comes to the > difference between SHOULD and should. MUST and must, I've > got that, but SHOULD and should -- they challenge me. >=20 > In this case, SHOULD seemed stronger than should, which I > wanted, but I wasn't up for MUST since I think that there > might be exceptions of which I am unaware and I didn't want to > needlessly constrain folks. >=20 > I'll drop the normative language and just say "should" and > move on here. >>>=20 >>> Section 4 paragraph 2 says "applications which employ Active >>> Leasequery ... will usually use an initial Bulk Leasequery ..." >>> What are the exceptions where this would not happen? Or is this >>> just the flow you expect Leasequery requestors to follow, but they >>> could just do an Active Leasequery starting at T=3D0 or something? = I >>> don't think this is going to cause an interop problem, but for >>> clarity it might be worth figuring out what you mean here by >>> "usually." If you really just mean that this is how it is done, >>> then you should probably say so more affirmatively. >=20 > Ok, we'll be more affirmative, but not normative.=20 >>>=20 >>> The organization of 6.2 is a bit odd: the first message is in 6.2, >>> and subsequent messages are in 6.2.1 and 6.2.2. This definitely >>> isn't going to cause interop problems, but it might make the table = of >>> contents look nicer if you put LEASEQUERY-REPLY in its own 6.2.x >>> subhead. >=20 > We did it this way because we are not defining a new message > in 6.2 -- LEASEQUERY-REPLY is already defined in RFC5007. >=20 > But we'll put that paragraph in its own section since you feel > it will be clearer. >>>=20 >>> In section 9.4, why all the text about multiple queries over the = same >>> connection? If the recommendation is to use two connections, why >>> not just require that? This seems like needless complexity. >=20 > Ok, we'll take it out. One connection per query. >>>=20 >>> In 9.5, why does it make sense for the server to finish processing >>> outstanding requests _after_ it has determined that the requestor = end >>> of the connection has been closed? If you mean that the requestor >>> has shut down transmission but is still receiving, then wouldn't = this >>> mean for an active leasequery that the server would continue sending >>> updates indefinitely after that? >=20 > Hmmm. Well, yes, I suppose that it does. I'll remove > that last sentence. >>>=20 >>> In 10, I don't think you need to talk about SYN flood attacks: this >>> is something that's typically dealt with in the stack. > =09 > Always happy to remove stuff. Its gone! >>>=20 >>> When you say that servers should restrict connections to certain >>> requestors, you don't say how those requestors are identified. I >>> would suggest that you use the client cert, or a local-CA-cert >>> signing the client cert, as that mechanism. Otherwise I think >>> you're relying on IP addresses, which would be a PITA to configure. >>> Which I suppose means I'm suggesting that you not bother with this >>> other than for TLS-secured connections. >=20 > Ok, we'll take that out too. >>>=20 >>> Aside from this modest set of comments, LGTM! :) >>>=20 >>> _______________________________________________ Int-dir mailing list=20= >>> Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir >>>=20 >>=20 >=20 From nobody Wed Jun 17 08:04:13 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063641A907D; Wed, 17 Jun 2015 08:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Stccx-3zgFDd; Wed, 17 Jun 2015 08:04:09 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5681A1E0F; Wed, 17 Jun 2015 08:04:06 -0700 (PDT) Received: by qcbfz6 with SMTP id fz6so14445559qcb.0; Wed, 17 Jun 2015 08:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=cjEDhcGwPtRYs6RW7CwJzNgXcr3qxy9wlnMW4BaOktE=; b=JR3DDqNNz4uQmor/YP4fwTW1GOTQ7cDTpn/5wzXLEnvl3GtnWHVsYaJRto8rwqQKje CL8CaHlYfJ5oPZkxQqe7t60dPeKueh8DyiAA4oQCoDgQy18ZiARlYghyaA2BwFMMqiY2 yY1HJ0bgLAKI9DzK/YdMhstcURMbFYpOhShW43J6kgiJC2pnRPq48GR5dINR0ALzMn5f VVxp5o/WwjocMxGbZ4ITkXJyYh+7bJ3lrmzYjN0Poi7QgFqtR1pufXZFDR3Hsbvoup1/ KeJIsuMiv16ok5s3MK71bh22AQODRlvvsT4vrmKvxw+g/YmNpokdAc5c7WtVGx6MfMiE WYsQ== X-Received: by 10.140.36.137 with SMTP id p9mr8363213qgp.16.1434553445632; Wed, 17 Jun 2015 08:04:05 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1004::4fa? ([2001:420:c0c4:1004::4fa]) by mx.google.com with ESMTPSA id m65sm2256937qhb.27.2015.06.17.08.04.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jun 2015 08:04:05 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2015 11:04:08 -0400 Message-Id: To: int-ads@tools.ietf.org, "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-6tisch-architecture.shepherd@ietf.org, draft-ietf-6tisch-architecture@tools.ietf.org, 6tisch-chairs@ietf.org Subject: [Int-dir] Internet Directorate review of draft-ietf-6tisch-architecture-08.txt X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 15:04:12 -0000 I am an assigned INT directorate reviewer for = . These comments were written = primarily for the benefit of the Internet Area Directors. Document = editors and shepherd(s) should treat these comments just like they would = treat comments from any other IETF contributors and resolve them along = with any other Last Call comments that have been received. For more = details on the INT Directorate, see = http://www.ietf.org/iesg/directorate.html. Summary ------- This document is not ready for publication. It needs to address several = technical and editorial issues before publication. In my opinion, the = document: * misses the intent of an "architecture" document * mixes high-level architecture with more complete design or = specification content * misses some architecture components * is incomplete and/or has been submitted for publication prior to = completion of the architecture design Substantive/technical issues ----------------------------- This document seems to be a work in progress. There are several = references to "first volume of the 6TiSCH architecture". In my opinion, = it should be possible to write a description of the architecture in a = single document. If not, then there should be a plan for what aspects = of the architecture will go into other volumes. This document can't be = assessed for completeness without some overview of the entire = architecture. It might be that the WG would be better served by = publishing the key components of this document in a more dynamic way, = such as in a wiki, and then publish the final architecture when the = component rotocols and specifications are complete. In my opinion, this document contains aspects of an architecture = document, a requirements document and a design specification. However, = it is missing some key aspect of each kind of document. For example, = section 8 gives what I consider to be a description of the communication = paradigms that are part of the architecture. The communication = paradigms are described (for the most part) in the abstract, without = specifying the design of how those paradigms are implemented. Section = 6, on the other hand, gives specific design details that would be better = expressed in a design or specification document. Similarly, section 10 = specifies the current, preliminary design for the join process, rather = than an architecture for security that describes all of the required = security functions and how they relate to each other. Several key pieces of the design and architecture are missing. While I = understand that this is the "first volume" of a suite of architecture = documents, it seems to me that decisions about: * How do applications interact with the network to request deterministic = behavior of a datagram, a flow, a bundle of flows? * How does the network report back to an application in the case where = the deterministic behavior can't be met, or in the case where the = network status has changed and an existing reservation can no longer be = met? * How is centralized track computation performed? * How will the PCE/NME interact with other, autonomous functions such as = the routing protocol? Or, will the PCE/NME control all forwarding? need to be made before decisions about the following can be made: * using a hierarchical multi-link subnet architecture * management protocols * routing protocols * scheduling protocols * fragment forwarding What, precisely, are the requirements? I see this text: traffic that is highly sensitive to jitter, quite sensitive to latency, and with a high degree of operational criticality so that loss should be minimized at all times. What are the time scales for jitter and latency - nanoseconds, = microseconds, milliseconds? What are acceptable loss rates? What are = the tradeoffs between loss and jitter/latency? What are the requirements for mobility? Do those requirements mandate = the hierarchical multi-link subnet architecture? I'm not a security person, but it seems to me that relying solely on L2 = security as described in section 10 is inadequate. The details of the = join procedure belong in another document. Editorial issues ---------------- I think the abstract should read something like: This document describes a network architecture that provides low-latency, low-jitter and high-reliability packet delivery. It combines a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of industrial deterministic applications. In general, try to avoid time-dependent references. For example: TSCH was introduced with the IEEE802.15.4e [IEEE802154e] amendment and will be wrapped up in the next revision of the IEEE802.15.4 standard. only makes sense at the time the document is published. Also try to = avoid "new"; for example, change: At the same time, a new breed of Time Sensitive Networks is being developed to enable traffic that is highly sensitive to jitter, quite sensitive to latency, and with a high degree of operational criticality so that loss should be minimized at all times. to: Time Sensitive Networks enable traffic that is highly sensitive to jitter, quite sensitive to latency, and with a high degree of operational criticality so that loss should be minimized at all times. What is the "different time scale" for TSN and TSCH? The document gives = no sense about the relative requirements and operational characteristics = of TSN and TSCH.=20 Explain in the Introduction (if I have this right) that the 6tisch = architecture uses route computation to allocate and schedule cells to = IPv6 packets. Rather than go into detail, for example, about using routing protocols = to distribute ND registrations, explain that the multi-link subnet = architecture requires extensions to NDP because not all hosts in a = subnet can communicate with each other directly. I can't find the term "mote" anywhere else in the document, nor is it a = widely used term, so the parenthetical "(also called motes)" is = unneeded. I think the reference to 6tisch-terminology should come first in section = 2. It took me a while to discover the importance of that document in = understanding this architecture document. The citation of "Multi-link Subnet Support in IPv6" = [I-D.ietf-ipv6-multilink-subnets] in the terminology section seems = inappropriate, as the document expired 13 years ago and the concept was = explicitly deprecated in RFC 4903. The overview in section 4 is helpful but provides some redundant details = and leaves out some others. In particular, what are the roles of the = PCE and NME, and what communication is required among them and the = various forwarding nodes to complete the schedule computation and = distribute the schedules? What are the architectural components of = route computation and update? It would help the reader understand the motivation for the multi-volume = architecture to move the first paragraph of section 5.1 to the = Introduction. Can sections 3, 4 and 5 be merged? They all appear to explain aspects = of an overview of the architecture. - Ralph Droms rdroms.ietf@gmail.com From nobody Mon Jun 29 07:51:18 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B338F1ACDC6; Mon, 29 Jun 2015 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXW2qhi-utCG; Mon, 29 Jun 2015 07:51:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA40B1ACDC2; Mon, 29 Jun 2015 07:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2041; q=dns/txt; s=iport; t=1435589474; x=1436799074; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g1DcNhRcsPHkElNWDjz3tF0ZmPU/xev/3wUeARD5fDM=; b=eyiLCn60z++/MBCxkjdpSLB0i9KiFgr6RXJCcoLlSx8TCHv5QdQlTPAS +OF6J8qzaLKqorpuNjCf4V2Tlelwz1j7tIeY7FKY8j6UABlJieapw9Hug I8Wi0BJTQd6UbCDGJnj16sOSp8AOsxqWYHhlA1sqj1XBcIIEI1g24oqsu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwAyWpFV/5RdJa1YA4MRVF8GvRgJgWaFeAKBNjgUAQEBAQEBAYEKhCIBAQEDAToPMAUHAgICAQgRBAEBCxQJBxYLERQJCAEBBAENBQgBiBEDCggNwjINhWwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBItGgk2CCCEQAgUGC4MGgRQFkSeCXQGEWIUZgx2EEYMNiEiHGyZjgxdvAYFFgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,699,1427760000"; d="scan'208";a="5549446" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jun 2015 14:51:14 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5TEpEp3031278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 14:51:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 09:51:13 -0500 From: "Bernie Volz (volz)" To: Ralf Weber , "int-dir@ietf.org" , "draft-vinapamula-softwire-dslite-prefix-binding@tools.ietf.org" Thread-Topic: INT Directorate - Seeking Directorate reviews Thread-Index: AdCtWgKd9uySzZtfTP29eynCrU7S/QFR5skAAAm7SvA= Date: Mon, 29 Jun 2015 14:51:13 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CB5216E@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1CB41327@xmb-rcd-x04.cisco.com> <02895A28-D94F-4553-8F35-BBC59F32BD08@nominum.com> In-Reply-To: <02895A28-D94F-4553-8F35-BBC59F32BD08@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.1.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Christopher LILJENSTOLPE \(cdl@asgaard.org\)" , "int-ads@ietf.org" , "jeanmichel.combes@gmail.com" Subject: Re: [Int-dir] INT Directorate - Seeking Directorate reviews X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 14:51:16 -0000 Thanks Ralf. Authors, please see below and note: "Ralf was an assigned INT directorate reviewer for draft-vinapamula-softwir= e-dslite-prefix-binding-05. These comments were written primarily for the b= enefit of the Internet Area Directors. Document editors and shepherd(s) sho= uld treat these comments just like they would treat comments from any other= IETF contributors and resolve them along with any other Last Call comments= that have been received. For more details on the INT Directorate, see http= ://www.ietf.org/iesg/directorate.html." - Bernie -----Original Message----- From: Ralf Weber [mailto:ralf.weber@nominum.com]=20 Sent: Monday, June 29, 2015 10:27 AM To: Bernie Volz (volz) Cc: jeanmichel.combes@gmail.com; int-ads@ietf.org; Christopher LILJENSTOLPE= (cdl@asgaard.org) Subject: Re: INT Directorate - Seeking Directorate reviews Moin! On 23 Jun 2015, at 4:15, Bernie Volz (volz) wrote: > Hi Ralf and Jean: > > Hopefully you guys can do the review for=20 > https://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-pref > ix-binding > as requested by Terry. Here we go: I've read the draft and am good with it. There is one thing that might be a= dded to it or it could also be that I not understood the protection mechani= sm. As per recommendations there now is one Tunnel (default value) per /56 or d= efined prefix instead of a /128. Now if someone from the same /56 connects = the CPE tunnel endpoint is switched if another session is initiated. Now co= uld that not be an DOS attack vector on the gateway, as an attacker can use= all of the prefix to constantly generate new tunnel endpoints causing the = gateway to migrate the traffic to the new endpoint. Should we not point tha= t out and maybe recommend some rate limiting on tunnel connections? So long -Ralf --- Ralf Weber Principal Architect, Special Projects office: +49 6446 4392053 mobile: +49 151 22659325 us: +1 650 817 5895 Nominum www.nominum.com ralf.weber@nominum.com From nobody Tue Jun 30 04:36:37 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561B91B371D; Tue, 30 Jun 2015 00:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q7AZ4jKiQJD; Tue, 30 Jun 2015 00:03:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5921F1B371A; Tue, 30 Jun 2015 00:03:14 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 87F232ACA88; Tue, 30 Jun 2015 09:03:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 5B383C804F; Tue, 30 Jun 2015 09:03:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 09:03:11 +0200 From: To: "Bernie Volz (volz)" , Ralf Weber Thread-Topic: INT Directorate - Seeking Directorate reviews Thread-Index: AdCtWgKd9uySzZtfTP29eynCrU7S/QFR5skAAAm7SvAADfpKcA== Date: Tue, 30 Jun 2015 07:03:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300533E109@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <489D13FBFA9B3E41812EA89F188F018E1CB41327@xmb-rcd-x04.cisco.com> <02895A28-D94F-4553-8F35-BBC59F32BD08@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1CB5216E@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CB5216E@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.30.61516 Archived-At: X-Mailman-Approved-At: Tue, 30 Jun 2015 04:36:36 -0700 Cc: "draft-vinapamula-softwire-dslite-prefix-binding@tools.ietf.org" , "Christopher LILJENSTOLPE \(cdl@asgaard.org\)" , "int-dir@ietf.org" , "int-ads@ietf.org" , "jeanmichel.combes@gmail.com" Subject: Re: [Int-dir] INT Directorate - Seeking Directorate reviews X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 07:03:16 -0000 Dear Bernie, Ralf, all, Thank you for the review. A misbehaving CPE can indeed vary the source IPv6 address it uses to send i= ts IPv4-in-IPv6 packets to the DS-Lite AFTR. If the AFTR maintains state fo= r each new softwire (from the same B4), then varying the source IPv6 addres= s can be a source of DoS attack that may exhaust the AFTR resources. A first mitigation to this attack vector is to limit the number of softwire= per B4 (already recorded in the draft). This countermeasure should be comp= lemented with rate limiting softwires with new source IPv6 from the same CP= E. A new version that includes changes to address your comment is available on= line: URL: https://www.ietf.org/internet-drafts/draft-vinapamula-softw= ire-dslite-prefix-binding-06.txt=20 Status: https://datatracker.ietf.org/doc/draft-vinapamula-softwire-= dslite-prefix-binding/=20 Htmlized: https://tools.ietf.org/html/draft-vinapamula-softwire-dslit= e-prefix-binding-06=20 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-vinapamula-softwi= re-dslite-prefix-binding-06=20 Cheers, Med > -----Message d'origine----- > De=A0: Bernie Volz (volz) [mailto:volz@cisco.com] > Envoy=E9=A0: lundi 29 juin 2015 16:51 > =C0=A0: Ralf Weber; int-dir@ietf.org; draft-vinapamula-softwire-dslite-pr= efix- > binding@tools.ietf.org > Cc=A0: jeanmichel.combes@gmail.com; int-ads@ietf.org; Christopher > LILJENSTOLPE (cdl@asgaard.org) > Objet=A0: RE: INT Directorate - Seeking Directorate reviews >=20 > Thanks Ralf. >=20 > Authors, please see below and note: >=20 > "Ralf was an assigned INT directorate reviewer for draft-vinapamula- > softwire-dslite-prefix-binding-05. These comments were written primarily > for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along with any > other Last Call comments that have been received. For more details on the > INT Directorate, see http://www.ietf.org/iesg/directorate.html." >=20 > - Bernie >=20 > -----Original Message----- > From: Ralf Weber [mailto:ralf.weber@nominum.com] > Sent: Monday, June 29, 2015 10:27 AM > To: Bernie Volz (volz) > Cc: jeanmichel.combes@gmail.com; int-ads@ietf.org; Christopher > LILJENSTOLPE (cdl@asgaard.org) > Subject: Re: INT Directorate - Seeking Directorate reviews >=20 > Moin! >=20 > On 23 Jun 2015, at 4:15, Bernie Volz (volz) wrote: >=20 > > Hi Ralf and Jean: > > > > Hopefully you guys can do the review for > > https://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-pref > > ix-binding > > as requested by Terry. > Here we go: >=20 > I've read the draft and am good with it. There is one thing that might be > added to it or it could also be that I not understood the protection > mechanism. >=20 > As per recommendations there now is one Tunnel (default value) per /56 or > defined prefix instead of a /128. Now if someone from the same /56 > connects the CPE tunnel endpoint is switched if another session is > initiated. Now could that not be an DOS attack vector on the gateway, as > an attacker can use all of the prefix to constantly generate new tunnel > endpoints causing the gateway to migrate the traffic to the new endpoint. > Should we not point that out and maybe recommend some rate limiting on > tunnel connections? >=20 > So long > -Ralf > --- > Ralf Weber > Principal Architect, Special Projects > office: +49 6446 4392053 > mobile: +49 151 22659325 > us: +1 650 817 5895 > Nominum > www.nominum.com > ralf.weber@nominum.com