From nobody Tue Apr 1 06:58:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5703C1A06BE for ; Tue, 1 Apr 2014 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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 W5Iyuc0zoDYO for ; Tue, 1 Apr 2014 06:58:21 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) by ietfa.amsl.com (Postfix) with ESMTP id 97E411A06D7 for ; Tue, 1 Apr 2014 06:58:20 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id s31DwGmX010195; Tue, 1 Apr 2014 09:58:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1396360696; bh=jI9MdPxyPeibz9LTqzWs5Y9+WGD6SpAyqqd8Q8FtHYE=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:In-Reply-To: References; b=edktW5SVPwv6UMV56ulZaKCzRXm++X4TRb3lCpdgU+yuqBx5REndIv0/OkPxszQe8 wfGPp9OA9xYkLSxxsZFRhr9YfSOXMmJZ8dQRQkYs27u53cf4JDt31kc5MyGOQeQD0P bNlouDXychmparGxdFqnqYu1InS4ll5Et316huWo= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id s31DwAAM012466; Tue, 1 Apr 2014 09:58:10 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.02.0347.000; Tue, 1 Apr 2014 09:58:10 -0400 From: Chris Inacio To: "secdir@ietf.org" Thread-Topic: Review of draft-ietf-opsec-lla-only-07 Thread-Index: AQHPTbJqVu4ROaamH0mX27NRO+xyPA== Date: Tue, 1 Apr 2014 13:58:10 +0000 Message-ID: <58AECC65-6DAF-4CA7-AA3D-5750218118F2@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.51.97] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/cLMzmw4OgUyAOnuOEwSfkqq8l10 Cc: "draft-ietf-opsec-lla-only-07@tools.ietf.org" Subject: [secdir] Review of draft-ietf-opsec-lla-only-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 13:58:22 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall impression is that this is a well written draft, and I didn=92t par= ticularly notice any editorial comments, although I wasn=92t focused on tha= t. The entire draft is dedicated to an informational router configuration that= encourages using link local addressing on the non-public facing router int= erfaces. The draft, as a whole does a good job describing and referencing = previous work on configuration and mitigation strategies to encourage a mo= re secure configuration. My only feedback is that the Security Considerations section might also inc= lude a sentence referencing all of the other RFC=92s and guidance previousl= y mentioned in the document: For additional security considerations, as previously stated, see also: [= RFC5837], [I-D.ietf-opsec-bgp-security]. and possible a statement saying that all other previous recommendations for= control plane security, etc. I do understand if this recommendation is not acted upon, it is difficult t= o summarize an entire document which is about configuration for security in= to a single concise paragraph at the end of the document. regards, -- Chris Inacio inacio@cert.org From nobody Thu Apr 3 03:57:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2A91A0232 for ; Thu, 3 Apr 2014 03:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Wb3vuETIs3YK for ; Thu, 3 Apr 2014 03:57:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A33A01A0221 for ; Thu, 3 Apr 2014 03:57:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s33AvAX7028722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Apr 2014 13:57:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s33AvAxM004896; Thu, 3 Apr 2014 13:57:10 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21309.16005.971323.36810@fireball.kivinen.iki.fi> Date: Thu, 3 Apr 2014 13:57:09 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/osGWtYG_cZP-ZWwH-c7SomB58ZA Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 10:57:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Charlie Kaufman is next in the rotation. For telechat 2014-04-03 Reviewer LC end Draft Derek Atkins T 2014-03-12 draft-ietf-ipsecme-ikev2-fragmentation-06 Sandy Murphy T 2014-03-05 draft-melnikov-smime-msa-to-mda-04 For telechat 2014-04-10 Rob Austein T 2014-03-24 draft-ietf-cdni-framework-10 Dorothy Gellert T 2014-04-01 draft-ietf-pcp-dhcp-11 Steve Hanna T 2014-03-28 draft-ietf-xrblock-rtcp-xr-loss-conceal-11 Last calls and special requests: Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Phillip Hallam-Baker 2014-04-01 draft-ietf-trill-esadi-06 Dan Harkins 2014-04-08 draft-ietf-idr-aigp-16 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2014-04-09 draft-ietf-mpls-psc-updates-03 Leif Johansson 2014-04-15 draft-ietf-ccamp-rsvp-te-eth-oam-ext-11 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Carl Wallace 2014-03-14 draft-drage-sipping-rfc3455bis-13 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Apr 3 07:20:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAEA1A01D5; Thu, 3 Apr 2014 07:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no 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 MCHwWFpPnG0G; Thu, 3 Apr 2014 07:20:32 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id D8A541A01CE; Thu, 3 Apr 2014 07:20:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1B58BE2034; Thu, 3 Apr 2014 10:20:27 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20433-01; Thu, 3 Apr 2014 10:20:24 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 78684E2033; Thu, 3 Apr 2014 10:20:24 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s33EKMux015976; Thu, 3 Apr 2014 10:20:22 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 03 Apr 2014 10:20:22 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/J1eEZPVDZ7QxYkWGvObpoSX_DXU Cc: ipsecme-chairs@tools.ietf.org, svan@elvis.ru Subject: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:20:36 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. I see no major issues with this document. There is still a minor issue where you move the exhaustion attack from the IP layer to the IKE layer -- an attacker could, theoretically, fill an IKE session with incomplete fragments causing it to use resources waiting for missing fragments. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 3 07:51:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92B11A01D7; Thu, 3 Apr 2014 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.301 X-Spam-Level: X-Spam-Status: No, score=-97.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no 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 kYKPVcMfMf-n; Thu, 3 Apr 2014 07:42:31 -0700 (PDT) Received: from bull.elvis.ru (bull.elvis.ru [93.188.44.194]) by ietfa.amsl.com (Postfix) with ESMTP id DE4251A01C2; Thu, 3 Apr 2014 07:42:30 -0700 (PDT) Received: from robin.office.elvis.ru ([10.111.1.40]) by bull.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1WViqU-0003yX-4F; Thu, 03 Apr 2014 18:42:22 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.1.438.0; Thu, 3 Apr 2014 18:42:22 +0400 Message-ID: From: Valery Smyslov To: Derek Atkins , , References: Date: Thu, 3 Apr 2014 18:42:20 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HESDQpBSpUdU2z_LkuLsUlDHMKA X-Mailman-Approved-At: Thu, 03 Apr 2014 07:51:50 -0700 Cc: ipsecme-chairs@tools.ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:42:35 -0000 Hi Derek, thank you for your review. Please see my comment inline. ----- Original Message ----- From: "Derek Atkins" To: ; Cc: ; Sent: Thursday, April 03, 2014 6:20 PM Subject: sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06 > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > I see no major issues with this document. > > There is still a minor issue where you move the exhaustion attack from > the IP layer to the IKE layer -- an attacker could, theoretically, > fill an IKE session with incomplete fragments causing it to use > resources waiting for missing fragments. Note, that in this proposal each IKE fragment is individually protected - encrypted and authenticated. Forged fragments will be detected before they are placed into reassembling queue and thus they couldn't exhaust receiver's resources - only fragments from real peer will be taken into consideration. And if attacker is capable enough to drop an arbitrary IP packet, than there is no protection anyway - the connection will fail on attacker's will in any case, with or without IKE fragmentation. Regards, Valery Smyslov. > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu Apr 3 08:00:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463541A01DC; Thu, 3 Apr 2014 08:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no 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 x1LDhEM5j01S; Thu, 3 Apr 2014 08:00:29 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 12EA61A01C2; Thu, 3 Apr 2014 08:00:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 29158E2033; Thu, 3 Apr 2014 11:00:24 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20433-10; Thu, 3 Apr 2014 11:00:20 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id CB478E2036; Thu, 3 Apr 2014 11:00:20 -0400 (EDT) Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 3 Apr 2014 11:00:20 -0400 Message-ID: <89fe86e74a6e22a538adcc0cc3db2489.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Thu, 3 Apr 2014 11:00:20 -0400 From: "Derek Atkins" To: "Valery Smyslov" User-Agent: SquirrelMail/1.4.22-13.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/AiJcd8V_HkKofppBQd-jp8JUVdM Cc: ipsecme-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:00:33 -0000 Hi, On Thu, April 3, 2014 10:42 am, Valery Smyslov wrote: >> >> There is still a minor issue where you move the exhaustion attack from >> the IP layer to the IKE layer -- an attacker could, theoretically, >> fill an IKE session with incomplete fragments causing it to use >> resources waiting for missing fragments. > > Note, that in this proposal each IKE fragment is individually protected - > encrypted and authenticated. Forged fragments will be detected > before they are placed into reassembling queue and thus they > couldn't exhaust receiver's resources - only fragments from real peer > will be taken into consideration. And if attacker is capable enough > to drop an arbitrary IP packet, than there is no protection > anyway - the connection will fail on attacker's will in any case, > with or without IKE fragmentation. It's only authenticated in the sense that you have to have already had a full round trip so yes, an attacker can not forge their source IP. But that doesn't prevent a true DDoS where real hosts (think botnet) all perform a real IKE_SA_INIT and then use their sessions to build a lot of held state with "fake" fragments that will never complete. Like I said, it's an improvement because it's not at the kernel IP layer, and theoretically there are more resources available at the IKE layer. But it probably should still be mentioned. (Not that IKE without fragmentation isn't also subject to this kind of DDoS attack). Thanks, > > Regards, > Valery Smyslov. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 3 08:19:04 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EC31A024E; Thu, 3 Apr 2014 08:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.301 X-Spam-Level: X-Spam-Status: No, score=-97.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no 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 c8vk2lLztqXq; Thu, 3 Apr 2014 08:18:57 -0700 (PDT) Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFEE1A0226; Thu, 3 Apr 2014 08:18:55 -0700 (PDT) Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1WVjPk-0006Hz-2U; Thu, 03 Apr 2014 19:18:48 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.1.438.0; Thu, 3 Apr 2014 19:18:48 +0400 Message-ID: <038E8235A7E047809B765B35F995772A@buildpc> From: Valery Smyslov To: Derek Atkins References: <89fe86e74a6e22a538adcc0cc3db2489.squirrel@mail2.ihtfp.org> Date: Thu, 3 Apr 2014 19:18:46 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fM0_hDA3FYhiwFHdSEOHSU6csvY Cc: ipsecme-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 15:19:01 -0000 Hi, >> Note, that in this proposal each IKE fragment is individually protected - >> encrypted and authenticated. Forged fragments will be detected >> before they are placed into reassembling queue and thus they >> couldn't exhaust receiver's resources - only fragments from real peer >> will be taken into consideration. And if attacker is capable enough >> to drop an arbitrary IP packet, than there is no protection >> anyway - the connection will fail on attacker's will in any case, >> with or without IKE fragmentation. > > It's only authenticated in the sense that you have to have already had a > full round trip so yes, an attacker can not forge their source IP. But No, it is fully cryptographically authenticated. IKE fragmentation may only take place after shared keys (SK_*) keys are computed. > that doesn't prevent a true DDoS where real hosts (think botnet) all > perform a real IKE_SA_INIT and then use their sessions to build a lot of > held state with "fake" fragments that will never complete. Messages of IKE_SA_INIT cannot be fragmented with this proposal, because SK_* are not yet computed. This is limitation, mentioned in the draft. It is assumed that IKE_SA_INIT messages can be made relatively small to avoid IP fragmentation. > Like I said, it's an improvement because it's not at the kernel IP layer, > and theoretically there are more resources available at the IKE layer. > But it probably should still be mentioned. (Not that IKE without > fragmentation isn't also subject to this kind of DDoS attack). As I've said, IKE_SA_INIT are beyond this proposal (and IKE_SA_RESUME also, if we count in IKE session resumption protocol). But messages of the other exchanges can be fragmented with full cryptographic protection, including authentication of each fragment, and I don't think this attack is possible here (and it was one of the goals to prevent this kind of attack). Regards, Valery. > Thanks, > >> >> Regards, >> Valery Smyslov. > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From nobody Thu Apr 3 09:03:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833121A0215; Thu, 3 Apr 2014 09:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eRg4D-9bTC8E; Thu, 3 Apr 2014 09:03:01 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id DC77D1A01FA; Thu, 3 Apr 2014 09:03:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DB13AE2033; Thu, 3 Apr 2014 12:02:54 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20895-04; Thu, 3 Apr 2014 12:02:52 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 6F06CE2034; Thu, 3 Apr 2014 12:02:52 -0400 (EDT) Received: from 192.168.248.230 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 3 Apr 2014 12:02:52 -0400 Message-ID: <0742c4d63ab2e4a6145633e3a76cedc0.squirrel@mail2.ihtfp.org> In-Reply-To: <038E8235A7E047809B765B35F995772A@buildpc> References: <89fe86e74a6e22a538adcc0cc3db2489.squirrel@mail2.ihtfp.org> <038E8235A7E047809B765B35F995772A@buildpc> Date: Thu, 3 Apr 2014 12:02:52 -0400 From: "Derek Atkins" To: "Valery Smyslov" User-Agent: SquirrelMail/1.4.22-13.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jrCtJtpMmEtnriGE9l8vQW9BUoQ Cc: ipsecme-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 16:03:06 -0000 Valery, At this point I expect we have a language issue. Either I am not explaining myself clearly or you are not understanding what I'm saying. Let me try to be more clear with what I mean inline below.. On Thu, April 3, 2014 11:18 am, Valery Smyslov wrote: > Hi, > >>> Note, that in this proposal each IKE fragment is individually protected >>> - >>> encrypted and authenticated. Forged fragments will be detected >>> before they are placed into reassembling queue and thus they >>> couldn't exhaust receiver's resources - only fragments from real peer >>> will be taken into consideration. And if attacker is capable enough >>> to drop an arbitrary IP packet, than there is no protection >>> anyway - the connection will fail on attacker's will in any case, >>> with or without IKE fragmentation. >> >> It's only authenticated in the sense that you have to have already had a >> full round trip so yes, an attacker can not forge their source IP. But > > No, it is fully cryptographically authenticated. IKE fragmentation > may only take place after shared keys (SK_*) keys are computed. The SK_ values are just the result of an unauthenticated DH exchange. There is no endpoint authentication yet. There is no endpoint identity. You've just exchanged a random number and computed a shared secret. You don't know if that shared secret is shared with a real player or a botnet player. Indeed, this is why we have the IKE_AUTH packets, to actually authenticate the endpoints to each other. So yes, you are correct that fragments are encrypted and "authenticated" the the Shared Key generated during IKE_SA_INIT. However at the end of IKE_SA_INIT all you know is that the peer is reachable. At this point the attacker can send you a bunch of bogus "authenticated" IKE_AUTH fragments and use your resources. >> that doesn't prevent a true DDoS where real hosts (think botnet) all >> perform a real IKE_SA_INIT and then use their sessions to build a lot of >> held state with "fake" fragments that will never complete. > > Messages of IKE_SA_INIT cannot be fragmented with this proposal, > because SK_* are not yet computed. This is limitation, mentioned in the > draft. > It is assumed that IKE_SA_INIT messages can > be made relatively small to avoid IP fragmentation. I did not say that they could. As the document clearly says (and I agree with), you don't fragment the IKE_SA_INIT packets. But that's not the attack I'm talking about. I said that an attacker completes IKE_SA_INIT and then (after you have a DH Computed Shared Key) it can send a bunch of bogus fragments. >> Like I said, it's an improvement because it's not at the kernel IP >> layer, >> and theoretically there are more resources available at the IKE layer. >> But it probably should still be mentioned. (Not that IKE without >> fragmentation isn't also subject to this kind of DDoS attack). > > As I've said, IKE_SA_INIT are beyond this proposal > (and IKE_SA_RESUME also, if we count in IKE session resumption > protocol). But messages of the other exchanges can be > fragmented with full cryptographic protection, including > authentication of each fragment, and I don't think this attack is possible > here (and it was one of the goals to prevent this kind of attack). Again, I'm not talking about IKE_SA_INIT (or IKE_SA_RESUME). I'm talking about AFTER that point, but before IKE_AUTH. The attacker still needs to perform work and be reachable. It needs to perform an IKE_SA_INIT round trip to compute a shared key with the target, but once it reaches that point it can send a bunch of bogus "authenticated" fragments and cause the target to use resources. For example the attacker could say that there are 2^16 IKE_AUTH fragments and then send a bunch of packets that each individually are "authenticated". Assume each packet is 1024 bytes but it only sends 2^16-1 of them. This would cause the target to use ~64MB of RAM per peer buffering the packets. As I said, this is an improvement over IP fragmentation and buffering in the kernel, but such an attack is still possible with this protocol. The GOOD news is that the attacked host can log this -- they know the actual source IP of the attack. But a botnet doesn't care. I hope you understand my point now? Thanks, > Regards, > Valery. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 3 10:18:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B26B1A0213; Thu, 3 Apr 2014 10:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CjVk6_-hz9Q4; Thu, 3 Apr 2014 10:17:51 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id A61D01A020E; Thu, 3 Apr 2014 10:17:50 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 6BBE228B003D; Thu, 3 Apr 2014 13:17:46 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5BACF1F8035; Thu, 3 Apr 2014 13:17:46 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Apr 2014 13:17:45 -0400 Message-Id: <4F2801E3-3D7E-462C-85E6-65548F1197B1@tislabs.com> To: iesg@ietf.org, secdir@ietf.org, draft-melnikov-smime-msa-to-mda@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ee4rAwNM1zfI5DQ8I3h1LX4u79Q Subject: [secdir] secdir comments on draft-melnikov-smime-msa-to-mda X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 17:17:56 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This draft updates (at least) RFC 3183. It changes the naming convention and corrects an erratum. The shepherd writeup seems to be based on an earlier version that did not include all the signature types in RFC3183. The writeup raises the possibility that the types not included could be deprecated or possibly move them to this draft and obsolete RFC3183. The current version now includes all the signature types from RFC3183 but it does not say that it intends to obsolete RFC3183. Also, the current draft was submitted at the end of the IETF Last Call and adds a new signature type "delegated originator signature." So, at least, this draft updates RFC3183. Many of the following comments come from text from RFC3183 that has not changed. I'm not sure it that makes them grandfathered in or not. The security considerations section notes some of the doing decryption at a DCA. It notes the possibility of exposure or corruption of a message either by a compromised DCA or somewhere between the DCA and the end user. This is true in any use of DOMSEC based services. In general, the recipient is trusting its own DCA to correctly report validation, or to uphold any of the security services (i.e., not to corrupt, expose or spoof the message). The same is true at the originating end user - the originator is trusting its own DCA to correctly validate the originator, to maintain the security services (not to corrupt, expose, or spoof the message), etc. And messages not protected between the originator/recipient and the sending/receiving agent are subject to damage. The delegated originator signatures seem to be a hybrid case - like originator signatures, they need not encapsulate other signatures (sec 3.2 page 10) but they also may encapsulate other signatures (sec 3.7 page 13). It is not clear when the delegated originator signatures are used in the un-encapsulated form. There are motivating descriptions of the other signature types in section 2, but not for the delegated originator signature type. Sections 5 talks about "domain signature" types, which is one of the DOMSEC-based signature types. It is not clear whether the other DOMSEC-based signature types are meant as well, particularly in the text that describes adding a new encapsulating signature. Section 3.2 page 10 notes that: A SignerInfo MUST NOT include multiple instances of SignatureType. A signed attribute representing a SignatureType MAY include multiple instances of different SignatureType values as an AttributeValue of attrValues [RFC5652], as long as the SignatureType 'additional attributes' is not present. Does this mean that one signature might be noted as a domain signature AND a review signature? A domain AND review AND delegated originator? Aside from the prohibition of the additional attributes types, are there other combinations that do not make sense? The descriptions of adding a DOMSEC-based signature type in 3.3-3.7 do not discuss when or whether an added DOMSEC-based signature might have multiple signature types. Section 2.6 describes the required relationship between a sending agent's certificate's name and the originator's certificate's name. This section is also referenced in section 4 when referring to the recipient and receiving agent. The symmetric case is pretty easy to see, but it would be nice to see it mentioned. Going sequentially through the document: Section 2, as noted above, has no description of delegated originator signature type. The need or uses or benefits were not obvious to me. It might be good for other readers to have a description. Section 2.5, page 7: A DOMSEC defined signature MAY encapsulate a message in one of the following ways: If not in one of these ways, then is no encapsulation performed? Some other encapsulation? If not in one of these ways, with the process of section 5 succeed? This applies particularly to the delegated originator signature type, which is allowed not to encapsulate an signature. Does that mean that it does not need to add the empty signature layer noted in part 1? However, the eContent field will contain the unsigned message instead of being left empty as suggested in section 5.2 in CMS [RFC5652]. Without checking RFC5652 - how do current CMS implementations treat that suggestion? IE, if an implementation of this standard is being built on an existing CMS implementation, with this departure from suggested practice run into problems? section 2.6, p8 For the other types of signature defined in future documents, no such namin rule is defined. I'm not sure what is being said here. *the* other types? do you mean "any other types"? are you making rules for future documents or saying you are making NO rules for future documents? "This naming convention does not apply to signature types define in future documents". Implementations MAY choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to secure exchange of messages. How is this agreed? Or expressed? Out of scope for this document? Note that a X.509 certificate of a signing Domain-based sending agent can be distinguished from a certificate of encrypting domain-based sending agent by checking for keyUsage as specified in [RFC5280] Section 4.2.1.3. RFC5280 section 4.2.1.3 says that the keyUsage field is used when there's an intended limitation of use - when the keys are to be used ONLY for a particular usage. Is there an implication in this statement that the sending/receiving agent keys MUST be so limited, so that the distinction can be made? section 3.3, page 11: If the originator's authenticity is successfully verified by one of the above methods and all other signatures present are valid, including those that have been encrypted, a 'domain signature' can be added to a message. Does that mean that a DOMSEC sending agent must be able to decrypt any encrypted layers of a message in order to add the domain signature? The text says: If the originator's authenticity is successfully verified by one of the above methods and all other signatures present are valid, including those that have been encrypted, a 'domain signature' can be added to a message. ... A recipient can assume that successful verification of the domain signature also authenticates the message originator. ... If there is no originator signature present, the only assumption that can be made is the domain the message originated from. Is that last statement consistent with the two prior? page 12 There MAY be one or more 'domain signature' signatures in an S/MIME encoding. (similar phrase appear in 3.4, 3.5) Since a signerInfo MUST NOT contain multiple SignatureTypes, this is talking about multiple encapsulation layers, right? Section 3.4 p 12: The following attributes have a special meaning, when present in an 'additional attributes' signature: I suspect you mean something like "when present in a SignerInfo containing an 'addiitonal attributes' signature. 3.5, p 13 An entity generating a review signature MUST do so using a certificate that follows the naming convention specified in Section 2.6. =20 ((You might run afoul of those who dislike text that says a signature is generated "using" a certificate. Of course, alternates that are not clumsy are hard to compose.)) 3.6, p 13 The 'originator signature' is used to indicate that the signer is the originator of the message and its contents. It is included in this document for completeness only. An originator signature is indicated either by the absence of the signature type attribute, or by the presence of the value id-sti-originatorSig in a 'signature type' signed attribute. So this is all going to be standard CMS, except for the additional signed attribute? 3.7, p 13 The 'delegated originator signature' is similar to the 'domain signature' (Section 3.3), but it also indicates that MSA signed message with a unique originator-specific key. It also need not encapsulate other signatures, so there's no need for the empty signature layer mentioned in 2.5, p7? If the originator's authenticity is successfully verified as specified in Section 3.3 and all other signatures present are valid, including those that have been encrypted, a 'delegated originator signature' can be added to a message. So sometimes a delegated originator signature DOES encapsulate other signatures? The discussion of delegated originator signatures follows the text of 3.3 fairly closely, but leaves off discussion of actions upon reception. Are they not to be performed for delegated originator signatures? It also leaves off the statement that in included in 3.3, 3.4 and 3.5 that there can be multiples of these signatures - is that not possible for delegated signature types? section 4.1, p 15 At the sender's domain, DCA encryption is achieved using the recipient DCA's certificate or the end recipient's certificate. For this, the encrypting process must be able to correctly locate the certificate for the corresponding DCA in the recipient's domain or the one corresponding to the end recipient. Having located the correct certificate, the encryption process is then performed and additional information required for decryption is conveyed to the recipient in the recipientInfo field as specified in CMS [RFC5652]. A DCA encryption agent MUST be named according to the naming convention specified in Section 2.6. This is so that the corresponding certificate can be found. Does "A DCA encryption agent" mean the recipient DCA? The terminology is a bit confusing. Also, Section 2.6 defines a relationship between sending agent name and originator name. How would that naming convention help to find the corresponding certificate? In RFC3183, the naming convention prescribed specific names, not just a relationship. This text might have worked in that case, but I'm not sure the text is applicable now. section 4.1, p16 2. The encrypting agent maps the recipient's name to the DCA name in the manner specified in Section 2.6. The user certificate attribute associated with the DCA's directory entry is then obtained. Again, section 2.6 in the current draft defines a relationship between the sending agent name and the originator name. It does not provide an explicit mapping rule. Section 5, p16 This section talks about 'domain signature' but is referenced by 3.7 for delegated originator signatures as well. (Section 5 is not mentioned in section 3.4-3.6 - the implication is that MLA stripping of review and additional attributes signatures is impossible or of no concern.) Should the text in section 5 be amended to make the application to delegated originator signatures clear? Section 5, p17 + Strip off all the signedData layers down to the envelopedData layer. The stripped outer layer signature's signedAttributes are remembered, = but not those of subsequent stripped signedData layers. The omission = seems deliberate, but it would be nice to have an explanation. (I did = not see the reason.) There is a possibility that the message will contain an envelopedData layer. This will be the case when the message has been encrypted within the domain for the domain's "Domain Confidentiality Authority" (see Section 4), and, possibly, the final recipient. ... 3. A. If an envelopedData layer has been found, then: ... + Locate the RecipientInfo for the local DCA and use the information it contains to obtain the message key. + Decrypt the encryptedContent using the message key. What about the case when the message has been encrypted for the final recipient? (Similar case on p18). p18: If no signedData layer containing a mlExpansionHistory attribute has been found and no envelopedData has been found, then: - 1. Strip off all the signedData layers down to the envelopedData "no envelopedData has been found" .... "down to the envelopedData" This sure looks like a typo, but I don't know what it should say. section 6.1, p21 The submit: URI scheme is used to designate SMTP Submission servers (e.g. listener endpoints, S/MIME agents performing Domain signing), SMTP accounts. =20 ^ and? or? p22 SMTP user names are UTF-8 strings and MUST be percent-encoded as required by the URI specification [RFC3986], Section 2.1. Where do SMTP user names appear in this URI scheme? I'm probably just clueless about the usual nomenclature here. Security considerations: Clients resolving smtp: URIs that wish to achieve data confidentiality "resolving smtp: URIs" - what does it mean to resolve a URI? (Could this maybe have meant to say "using smtp: URIs"? (same comments in section 6.2) --Sandy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nits: Please define MUA. p4 2. PKI deployment issues: There may not be any certificate paths between two organizations. Or an organization may be sensitive about aspects of its PKI and unwilling to expose them to outside access.=20 The part that starts "Or an..." is a sentence fragment. In Section 1, 1-4 (from RFC3183) are phrased as :problem = description but 5 is :solution. Section 2 - a domain is defined as having a common business function and a physical boundary. Could this technology also be used for a set of end users who meet the mutual trust criteria only? a virtual domain? Lots and lots of cases where an introductory subordinate clause or phrase is not separated from the main clause by a comma. The RFC Editor may have preferences there, I'll leave it to them. p8 - "namin rule" -> "naming rule" Note that a X.509 certificate of a signing Domain-based sending agent can be distinguished from a certificate of encrypting domain-based ^an The subject name of the Domain-based sending agent's X.509 ... Any message received where the domain part of the domain signing agent's name signing agent or sending agent? inconsistent use of quotes: 'domain signature' vs domain signature, = 'originator signature' vs originator signature, vs 'additional = attributes' signature, etc. p 9 "signers name" -> "signer's name" p17 How the 'domain signature' is applied will depend on what is already present within the message. Before the 'domain signature' can be applied the message MUST be searched for the "outer" signedData layer, this search is complete when one of the following is found: layer. This search p23 "end users DCA" -> "end user's DCA" From nobody Thu Apr 3 23:25:31 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD3D1A036B; Thu, 3 Apr 2014 23:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no 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 CCKsUSJsWt-q; Thu, 3 Apr 2014 23:25:21 -0700 (PDT) Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE721A032A; Thu, 3 Apr 2014 23:25:20 -0700 (PDT) Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1WVxYu-0007ge-8S; Fri, 04 Apr 2014 10:25:12 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.1.438.0; Fri, 4 Apr 2014 10:25:12 +0400 Message-ID: <516C9EDCE7F04741BD354D1BDBA94E17@buildpc> From: Valery Smyslov To: Derek Atkins References: <89fe86e74a6e22a538adcc0cc3db2489.squirrel@mail2.ihtfp.org> <038E8235A7E047809B765B35F995772A@buildpc> <0742c4d63ab2e4a6145633e3a76cedc0.squirrel@mail2.ihtfp.org> Date: Fri, 4 Apr 2014 10:25:10 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/4MclwdNGWTfaAtpWg3SSn8XFKFA Cc: ipsecme-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-ipsecme-ikev2-fragmentation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 06:25:25 -0000 Hi Derek, sorry for my slow understanding, now I got your idea. Please, see my comments inline. > Valery, > > At this point I expect we have a language issue. Either I am not > explaining myself clearly or you are not understanding what I'm saying. > Let me try to be more clear with what I mean inline below.. > > On Thu, April 3, 2014 11:18 am, Valery Smyslov wrote: >> Hi, >> >>>> Note, that in this proposal each IKE fragment is individually protected >>>> - >>>> encrypted and authenticated. Forged fragments will be detected >>>> before they are placed into reassembling queue and thus they >>>> couldn't exhaust receiver's resources - only fragments from real peer >>>> will be taken into consideration. And if attacker is capable enough >>>> to drop an arbitrary IP packet, than there is no protection >>>> anyway - the connection will fail on attacker's will in any case, >>>> with or without IKE fragmentation. >>> >>> It's only authenticated in the sense that you have to have already had a >>> full round trip so yes, an attacker can not forge their source IP. But >> >> No, it is fully cryptographically authenticated. IKE fragmentation >> may only take place after shared keys (SK_*) keys are computed. > > The SK_ values are just the result of an unauthenticated DH exchange. > There is no endpoint authentication yet. There is no endpoint identity. > You've just exchanged a random number and computed a shared secret. You > don't know if that shared secret is shared with a real player or a botnet > player. Indeed, this is why we have the IKE_AUTH packets, to actually > authenticate the endpoints to each other. Fully agree. > So yes, you are correct that fragments are encrypted and "authenticated" > the the Shared Key generated during IKE_SA_INIT. However at the end of > IKE_SA_INIT all you know is that the peer is reachable. At this point the > attacker can send you a bunch of bogus "authenticated" IKE_AUTH fragments > and use your resources. Sure. But note, that similar attack is possible without IKE fragmentation. Attacker (botnet) may send unfragmented IKE_AUTH message without AUTH payload (pretending to use EAP for authentication) and then stop sending anything. In this case server will spend roughly the same (*) amount of resources as in attack you described, so IKE fragmentation doesn't make server more succeptible to this kind of attack. (*) You may argue, that in the attack you described botnet may send a very large number of fragments, indicating that original unfragmented message is very large, thus forcing server to use more memory to store them. But implementation may limit the maximum number of fragments it accepts to some reasonable value and reject connection with higher number of fragments. And in attack with EAP the server will probably allocate some resources to communicate with AAA server, and probably even will send first request to it, causing creating the state on it. So, it is difficult to directly compare the impacts of these attacks, but IMHO they are _roughly_ the same. >>> that doesn't prevent a true DDoS where real hosts (think botnet) all >>> perform a real IKE_SA_INIT and then use their sessions to build a lot of >>> held state with "fake" fragments that will never complete. >> >> Messages of IKE_SA_INIT cannot be fragmented with this proposal, >> because SK_* are not yet computed. This is limitation, mentioned in the >> draft. >> It is assumed that IKE_SA_INIT messages can >> be made relatively small to avoid IP fragmentation. > > I did not say that they could. As the document clearly says (and I agree > with), you don't fragment the IKE_SA_INIT packets. But that's not the > attack I'm talking about. I said that an attacker completes IKE_SA_INIT > and then (after you have a DH Computed Shared Key) it can send a bunch of > bogus fragments. Now I got your point. >>> Like I said, it's an improvement because it's not at the kernel IP >>> layer, >>> and theoretically there are more resources available at the IKE layer. >>> But it probably should still be mentioned. (Not that IKE without >>> fragmentation isn't also subject to this kind of DDoS attack). >> >> As I've said, IKE_SA_INIT are beyond this proposal >> (and IKE_SA_RESUME also, if we count in IKE session resumption >> protocol). But messages of the other exchanges can be >> fragmented with full cryptographic protection, including >> authentication of each fragment, and I don't think this attack is >> possible >> here (and it was one of the goals to prevent this kind of attack). > > Again, I'm not talking about IKE_SA_INIT (or IKE_SA_RESUME). I'm talking > about AFTER that point, but before IKE_AUTH. OK. > The attacker still needs to perform work and be reachable. It needs to > perform an IKE_SA_INIT round trip to compute a shared key with the target, > but once it reaches that point it can send a bunch of bogus > "authenticated" fragments and cause the target to use resources. > > For example the attacker could say that there are 2^16 IKE_AUTH fragments > and then send a bunch of packets that each individually are > "authenticated". Assume each packet is 1024 bytes but it only sends > 2^16-1 of them. This would cause the target to use ~64MB of RAM per peer > buffering the packets. Yes, this is possible. But see my comments above. And an implementation may limit the maximum number of fragments it accepts, taking into consideration the size of fragments. The guidlines could be the following. Firstly, IKE fragmentation is optional, so it must be possible to send any IKE message without fragmentation. And it places some restrictions on message size - it must fit into UDP, i.e. be less that 64Kb. So, when you receive IKE fragments, you may safely assume, that total size of all fragments must not exceed 64Kb (plus some overhead). Taking into consideration the size of fragments you have been receiving, you may calculate the maximum number of fragments that makes sense to accept. For example, in situation you described, implementation should have limit the number of fragments to about 70 (due to overhead), and reject connection if peer indicated higher value. And secondly, implementation may furter limit the number of fragments it accepts with some configurable option. Most real IKE_AUTH messages are less than a few Kb in size, especially from road warriors, so in most cases it is safe to assume that real peer will never send larger messages and to accept only those values for the number of fragments, that results in unfragmented messages of this or smaller size. > As I said, this is an improvement over IP fragmentation and buffering in > the kernel, but such an attack is still possible with this protocol. Unfortunately, DoS attack is always possible with any protocol :-) > The GOOD news is that the attacked host can log this -- they know the > actual source IP of the attack. But a botnet doesn't care. > > I hope you understand my point now? I hope so. And I also hope you will understand my comments on this. Regards, Valery. > Thanks, > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From nobody Thu Apr 10 05:59:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9C81A008E for ; Thu, 10 Apr 2014 05:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, 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 jIWqiJNkLtLs for ; Thu, 10 Apr 2014 05:59:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF01A0275 for ; Thu, 10 Apr 2014 05:59:28 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s3ACxNhR005080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Apr 2014 15:59:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s3ACw8Bp028300; Thu, 10 Apr 2014 15:58:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21318.38240.68589.36417@fireball.kivinen.iki.fi> Date: Thu, 10 Apr 2014 15:58:08 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/h1ys1lhTjEYHnx8UCR35EjpQ_sk Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:59:35 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Stephen Kent is next in the rotation. For telechat 2014-04-10 Reviewer LC end Draft Rob Austein T 2014-03-24 draft-ietf-cdni-framework-10 Dorothy Gellert T 2014-04-01 draft-ietf-pcp-dhcp-11 Steve Hanna T 2014-03-28 draft-ietf-xrblock-rtcp-xr-loss-conceal-11 Carl Wallace T 2014-03-14 draft-drage-sipping-rfc3455bis-13 For telechat 2014-04-24 Charlie Kaufman T 2014-04-23 draft-ietf-precis-framework-15 Last calls and special requests: Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Phillip Hallam-Baker 2014-04-01 draft-ietf-trill-esadi-06 Dan Harkins 2014-04-08 draft-ietf-idr-aigp-17 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2014-04-09 draft-ietf-mpls-psc-updates-03 Leif Johansson 2014-04-15 draft-ietf-ccamp-rsvp-te-eth-oam-ext-11 Scott Kelly 2014-04-18 draft-kivinen-ipsecme-ikev2-rfc5996bis-02 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Apr 10 06:37:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB351A01AD; Thu, 10 Apr 2014 06:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 tzEbL1n43YUZ; Thu, 10 Apr 2014 06:37:53 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5A44F1A01C1; Thu, 10 Apr 2014 06:37:53 -0700 (PDT) Received: from mail1-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE024.bigfish.com (10.3.207.146) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Apr 2014 13:37:28 +0000 Received: from mail1-am1 (localhost [127.0.0.1]) by mail1-am1-R.bigfish.com (Postfix) with ESMTP id 6F8924A035C; Thu, 10 Apr 2014 13:37:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzdchzz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail1-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(189002)(199002)(86362001)(85852003)(74316001)(46102001)(80022001)(81542001)(81342001)(87936001)(76482001)(66066001)(83072002)(92566001)(76576001)(2201001)(50986999)(54356999)(77096999)(2656002)(31966008)(77982001)(80976001)(4396001)(83322001)(74662001)(74502001)(20776003)(99396002)(33646001)(79102001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB740; H:BLUPR05MB737.namprd05.prod.outlook.com; FPR:BC28F0AA.8F126508.40D7F14C.46FFC211.20271; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail1-am1 (localhost.localdomain [127.0.0.1]) by mail1-am1 (MessageSwitch) id 1397137046751906_23680; Thu, 10 Apr 2014 13:37:26 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.236]) by mail1-am1.bigfish.com (Postfix) with ESMTP id AA32F30005E; Thu, 10 Apr 2014 13:37:26 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Apr 2014 13:37:26 +0000 Received: from BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Thu, 10 Apr 2014 13:37:49 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) with Microsoft SMTP Server (TLS) id 15.0.913.9; Thu, 10 Apr 2014 13:37:46 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0913.002; Thu, 10 Apr 2014 13:37:46 +0000 From: Stephen Hanna To: The IESG , "secdir@ietf.org" , "draft-ietf-xrblock-rtcp-xr-loss-conceal.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-11.txt Thread-Index: Ac9Uwg0TQPUFa/57STOHpKA/9IWsSA== Date: Thu, 10 Apr 2014 13:37:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-forefront-prvs: 0177904E6B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MUCUewSVWvHDjveC3yJqJ9vQNbg Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:37:55 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document is "Ready with nits". This document defines two RTCP XR Report Blocks that allow the reporting of concealment metrics for audio applications of RTP. In layman's terms, this allows an audio receiver to report back on how much the audio is being mangled by packet loss. >From a security perspective, this document is fine. The security considerations section says that this document introduces no new security considerations beyond those described in [RFC3611]. I agree. I do have one nit that I wanted to ask about. At the very end of section 3.2, the Mean Playout Interrupt Size is defined to be 32 bits long. However, the second paragraph of this definition says: If the measured value exceeds 0xFFFD, the value 0xFFFE MUST be reported to indicate an over-range measurement. If the measurement is unavailable, the value 0xFFFF MUST be reported. Shouldn't those constants be 0xFFFFFFFD, 0xFFFFFFFE, and 0xFFFFFFFF? Thanks, Steve P.S. I apologize for sending this review late. However, I believe that it's still before the IESG telechat on this document so I hope that it will have some value. From nobody Thu Apr 10 18:13:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1AE1A0191; Thu, 10 Apr 2014 18:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.816 X-Spam-Level: * X-Spam-Status: No, score=1.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 BenR3OA1BN70; Thu, 10 Apr 2014 18:13:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 49BF11A0160; Thu, 10 Apr 2014 18:13:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFM80348; Fri, 11 Apr 2014 01:13:16 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Apr 2014 02:11:55 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Apr 2014 02:13:14 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 11 Apr 2014 09:13:07 +0800 From: Qin Wu To: Stephen Hanna , The IESG , "secdir@ietf.org" , "draft-ietf-xrblock-rtcp-xr-loss-conceal.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-11.txt Thread-Index: Ac9Uwg0TQPUFa/57STOHpKA/9IWsSAAYNQAg Date: Fri, 11 Apr 2014 01:13:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.114] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/FHM7yZrrThpo8RqfK4NDnG1L3ck Subject: [secdir] =?gb2312?b?tPC4tDogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRm?= =?gb2312?b?LXhyYmxvY2stcnRjcC14ci1sb3NzLWNvbmNlYWwtMTEudHh0?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 01:13:30 -0000 Q29ycmVjdCwgSSBoYXZlIGJlZW4gYXdhcmUgb2YgdGhpcyBuaXQgd2hlbiBJIGdvIHRocm91Z2gg UGV0ZScgcHJvcG9zZWQgY2hhbmdlIGR1cmluZyBJRVNHIHJldmlldy4NClRoYW5rcyBmb3IgY2F0 Y2hpbmcgdGhpcyBhbmQgYnJpbmdpbmcgaXQgdXAuIFdlIHdpbGwgZml4IHRoaXMgaW4gdGhlIHVw ZGF0ZS4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBTdGVw aGVuIEhhbm5hIFttYWlsdG86c2hhbm5hQGp1bmlwZXIubmV0XSANCreiy83KsbzkOiAyMDE0xOo0 1MIxMMjVIDIxOjM4DQrK1bz+yMs6IFRoZSBJRVNHOyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWll dGYteHJibG9jay1ydGNwLXhyLWxvc3MtY29uY2VhbC5hbGxAdG9vbHMuaWV0Zi5vcmcNCtb3zOI6 IHNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItbG9zcy1jb25jZWFs LTExLnR4dA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEg ZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0K VGhpcyBkb2N1bWVudCBpcyAiUmVhZHkgd2l0aCBuaXRzIi4NCg0KVGhpcyBkb2N1bWVudCBkZWZp bmVzIHR3byBSVENQIFhSIFJlcG9ydCBCbG9ja3MgdGhhdCBhbGxvdyB0aGUgcmVwb3J0aW5nIG9m IGNvbmNlYWxtZW50IG1ldHJpY3MgZm9yIGF1ZGlvIGFwcGxpY2F0aW9ucyBvZiBSVFAuDQpJbiBs YXltYW4ncyB0ZXJtcywgdGhpcyBhbGxvd3MgYW4gYXVkaW8gcmVjZWl2ZXIgdG8gcmVwb3J0IGJh Y2sgb24gaG93IG11Y2ggdGhlIGF1ZGlvIGlzIGJlaW5nIG1hbmdsZWQgYnkgcGFja2V0IGxvc3Mu DQoNCkZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwgdGhpcyBkb2N1bWVudCBpcyBmaW5lLiBU aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzYXlzIHRoYXQgdGhpcyBkb2N1bWVu dCBpbnRyb2R1Y2VzIG5vIG5ldyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBiZXlvbmQgdGhvc2Ug ZGVzY3JpYmVkIGluIFtSRkMzNjExXS4NCkkgYWdyZWUuDQoNCkkgZG8gaGF2ZSBvbmUgbml0IHRo YXQgSSB3YW50ZWQgdG8gYXNrIGFib3V0LiBBdCB0aGUgdmVyeSBlbmQgb2Ygc2VjdGlvbiAzLjIs IHRoZSBNZWFuIFBsYXlvdXQgSW50ZXJydXB0IFNpemUgaXMgZGVmaW5lZCB0byBiZQ0KMzIgYml0 cyBsb25nLiBIb3dldmVyLCB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiB0aGlzIGRlZmluaXRpb24N CnNheXM6DQoNCiAgICAgIElmIHRoZSBtZWFzdXJlZCB2YWx1ZSBleGNlZWRzIDB4RkZGRCwgdGhl IHZhbHVlIDB4RkZGRSBNVVNUIGJlDQogICAgICByZXBvcnRlZCB0byBpbmRpY2F0ZSBhbiBvdmVy LXJhbmdlIG1lYXN1cmVtZW50LiAgSWYgdGhlDQogICAgICBtZWFzdXJlbWVudCBpcyB1bmF2YWls YWJsZSwgdGhlIHZhbHVlIDB4RkZGRiBNVVNUIGJlIHJlcG9ydGVkLg0KDQpTaG91bGRuJ3QgdGhv c2UgY29uc3RhbnRzIGJlIDB4RkZGRkZGRkQsIDB4RkZGRkZGRkUsIGFuZCAweEZGRkZGRkZGPw0K DQpUaGFua3MsDQoNClN0ZXZlDQoNClAuUy4gSSBhcG9sb2dpemUgZm9yIHNlbmRpbmcgdGhpcyBy ZXZpZXcgbGF0ZS4gSG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgaXQncyBzdGlsbCBiZWZvcmUgdGhl IElFU0cgdGVsZWNoYXQgb24gdGhpcyBkb2N1bWVudCBzbyBJIGhvcGUgdGhhdCBpdCB3aWxsIGhh dmUgc29tZSB2YWx1ZS4NCg0KDQo= From nobody Fri Apr 11 14:13:42 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3F51A02EA; Fri, 11 Apr 2014 14:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1397250732; bh=DbmpWxMfJGTpw4dHZzq06afzflhljbZjWcDc/ZyrmHQ=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SgTvP25s/RDbE/RN//nUjaLVny4/3lFgswp+8UdllqGMUMlkjgo1S6P3C/paXvhUV O9E1lEDnh0A68Mtv4Hlnc0ie15rs+SRxd8wbHDejekYiDbb2T5OUa8mKgi/VJxfHph k1ogSR/utB9/03uPTXVydyCdWD7LPC539HrlLtJk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828A71A0299 for ; Fri, 11 Apr 2014 14:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 J9nlThCve63t for ; Fri, 11 Apr 2014 14:12:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 231151A01DF for ; Fri, 11 Apr 2014 14:12:08 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411211208.10163.23239.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 14:12:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/jUI75ffjhJYWog9bstEbl0YBYt4 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/InV5c-xeRUfjEegjhB4PfM7LqjA X-Mailman-Approved-At: Fri, 11 Apr 2014 14:13:25 -0700 Subject: [secdir] [new-work] WG Review: JavaScript Object Notation (json) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:12:12 -0000 The JavaScript Object Notation (json) working group in the Applications Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-04-21. JavaScript Object Notation (json) ------------------------------------------------ Current Status: Active WG Chairs: Matthew Miller Paul Hoffman Assigned Area Director: Pete Resnick Mailing list Address: json@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/json Archive: http://www.ietf.org/mail-archive/web/json/ Charter: Javascript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard, and is published in RFC 7159. The WG will work on an restricted profile of JSON designed to maximize interoperability. The work will start from draft-bray-i-json-01. The WG will work on a format for a streamable sequence of JSON texts. The work will start from draft-williams-json-text-sequence-00. Milestones: Jun 2014 - IETF Last Call for restricted profile Jun 2014 - IETF Last Call for text sequences _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Apr 15 14:05:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F201A07E7 for ; Tue, 15 Apr 2014 14:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 HPbpndpCzw9T for ; Tue, 15 Apr 2014 14:05:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 853201A038C for ; Tue, 15 Apr 2014 14:05:03 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50054) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WaAXH-00094E-64; Tue, 15 Apr 2014 17:04:55 -0400 Message-ID: <534D9EF6.4060106@bbn.com> Date: Tue, 15 Apr 2014 17:04:54 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: secdir , zhliu@gsta.com, lizho.jin@gmail.com, chen.ran@zte.com.cn, dcai@cisco.com, ssalam@cisco.com, Adrian Farrel , giheron@cisco.com, nabil.n.bitar@verizon.com Content-Type: multipart/alternative; boundary="------------000902050600030401040501" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ate9KxvtNzFK6VSfC5qeKIQCiZU Subject: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 21:05:09 -0000 This is a multi-part message in MIME format. --------------000902050600030401040501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors and WG chairs should treat these comments just like any other last call comments. This is a very brief document, just 12 pages. The Abstract for this document, n its entirety, says: "In many existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC 4762 with node and link redundancy in both domains." Unfortunately, this confusing wording is typical of the writing in several areas of this document. The RFC Editor will need to work closely with the authors to make this document easier to read. Also, there are several instances of acronyms used without expansion (e.g., ASBR), making reading even harder. I like the fact that the document includes a "Motivation" section. It provided a good description of why a new approach to achieving redundancy in the VPLS context is needed. Section 5 ends with a curious statement: There are two PW redundancy modes defined in [RFC6870]: Independent mode and Master/Slave mode.For the inter- domain four-PW scenario, it is required for PEs to ensure that the same mode is supported on the two ICCP peers in the same RG.One method to ensure mode consistency is by manual operation.Other methods are also possible and are out of the scope of this document. This says that two ASes have to ensure that both employ the same redundancy mode choice, notes that they can verify this manually, and that says there are other options to meet this requirement, but provides no description of the other options.Not very useful. Sections 5.1.1-3 provide switchover rules for redundancy. Sections 5.1.1 and 5.1.2 both include SHOULDs, but 5.1.3 contains no analogous RFC 2119 key words. This lack of parallelism is confusing. Section 5.3 describes switchover operation in the more complex four PW cases. It contains some RFC 2119 key words, but there are several instances of lowercase "should". Is this intentional? The Security Considerations section is brief, only 4 short paragraphs.It cites the Security Considerations sections of RFCs 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the solution described here. RFC 4762 also contains a brief Security Considerations section, referring the reader to RFC 4111, the PPVPN Security Framework. That document discusses security in detail, although most of the discussion does not appear to be directly applicable to the redundancy mechanisms of this document. RFC 6870 is directly relevant. It contains a two-sentence Security Considerations section (almost a record for brevity?) with a lowercase "must" for emphasis? This section refers to RFC 4447, which contains a meaningful SC section (finally). That document mandates use of the TCP/MD5 option for LDP. This is almost consistent with the second paragraph of the SC section in this document (which weakens this to a MAY), but not with the third paragraph (which seems to call for TCP-AO). The SC section of draft-ietf-pwe3-iccp calls for use of TCP-AO (SHOULD), which reinforces the references in the third paragraph of this SC, but is inconsistent with the second paragraph! The second paragraph in the SC section of this document uses a lowercase "could." I wonder if this should be uppercase, as per RFC 6919 J? The next paragraph directs implementers to three RFCs (6941, 6952, and 5925), and specifically cites TCP-AO. This is confusing guidance, given the MAY for TCP/MD5 use with LDP in the previous paragraph. Merely calling attention to these docs is not useful guidance. The final paragraph of this section contains two obvious spelling errors in the first sentence: The *activitiy* on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial of service *attackes*. Even if the spelling errors are corrected, it is not clear what value this sentence adds. The remaining two sentences of the paragraph provide useful guidance, and thus should be retained. My bottom line: the SC section of this document is internally inconsistent and conflicts with SC guidance in several of the other docs cited in the SC section. This needs --------------000902050600030401040501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This is a very brief document, just 12 pages. The Abstract for this document, n its entirety, says: “In many existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC 4762 with node and link redundancy in both domains.”

 

Unfortunately, this confusing wording is typical of the writing in several areas of this document. The RFC Editor will need to work closely with the authors to make this document easier to read. Also, there are several instances of acronyms used without expansion (e.g., ASBR), making reading even harder.

 

I like the fact that the document includes a “Motivation” section. It provided a good description of why a new approach to achieving redundancy in the VPLS context is needed.

 

Section 5 ends with a curious statement:

 

There are two PW redundancy modes defined in [RFC6870]:

Independent mode and Master/Slave mode.  For the inter-

domain four-PW scenario, it is required for PEs to ensure

that the same mode is supported on the two ICCP peers in

the same RG.  One method to ensure mode consistency is by

manual operation.  Other methods are also possible and are

out of the scope of this document.

 

This says that two ASes have to ensure that both employ the same redundancy mode choice, notes that they can verify this manually, and that says there are other options to meet this requirement, but provides no description of the other options.  Not very useful.

 

Sections 5.1.1-3 provide switchover rules for redundancy. Sections 5.1.1 and 5.1.2 both include SHOULDs, but 5.1.3 contains no analogous RFC 2119 key words. This lack of parallelism is confusing.

 

Section 5.3 describes switchover operation in the more complex four PW cases. It contains some RFC 2119 key words, but there are several instances of lowercase “should”. Is this intentional?

 

The Security Considerations section is brief, only 4 short paragraphs.  It cites the Security Considerations sections of RFCs 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the solution described here.

 

RFC 4762 also contains a brief Security Considerations section, referring the reader to RFC 4111, the PPVPN Security Framework. That document discusses security in detail, although most of the discussion does not appear to be directly applicable to the redundancy mechanisms of this document.

 

RFC 6870 is directly relevant. It contains a two-sentence Security Considerations section (almost a record for brevity?) with a lowercase “must” for emphasis? This section refers to RFC 4447, which contains a meaningful SC section (finally). That document mandates use of the TCP/MD5 option for LDP. This is almost consistent with the second paragraph of the SC section in this document (which weakens this to a MAY), but not with the third paragraph (which seems to call for TCP-AO).

 

The SC section of draft-ietf-pwe3-iccp calls for use of TCP-AO (SHOULD), which reinforces the references in the third paragraph of this SC, but is inconsistent with the second paragraph!

 

The second paragraph in the SC section  of this document uses a lowercase “could.” I wonder if this should be uppercase, as per RFC 6919 J? The next paragraph directs implementers to three RFCs (6941, 6952, and 5925), and specifically cites TCP-AO. This is confusing guidance, given the MAY for TCP/MD5 use with LDP in the previous paragraph. Merely calling attention to these docs is not useful guidance.

 

The final paragraph of this section contains two obvious spelling errors in the first sentence:

 

The activitiy on the inter-domain and intra-domain

pseudowire may cause security threats or be exploited to

create denial of service attackes.

 

Even if the spelling errors are corrected, it is not clear what value this sentence adds. The remaining two sentences of the paragraph provide useful guidance, and thus should be retained.

 

My bottom line: the SC section of this document is internally inconsistent and conflicts with SC guidance in several of the other docs cited in the SC section. This needs --------------000902050600030401040501-- From nobody Wed Apr 16 08:34:52 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A8F1A0215 for ; Wed, 16 Apr 2014 08:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 hYjy0JPwCK1m for ; Wed, 16 Apr 2014 08:34:46 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CD73F1A01FF for ; Wed, 16 Apr 2014 08:34:45 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so10776385pdj.6 for ; Wed, 16 Apr 2014 08:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=jb2RTZlUMDskgqYqJfNpsNfkBZV3VlIO89vPNGS6jh4=; b=0ZbIKtdPA6O1s6fZaIJ/S+HcTS25QjzDoxOk05a1OimvXIl2TGJKu7GRPO+pr3WdP3 PFaQPi60BmmjeE9NyJiOjQSX4Iujk92Ne9E98oBCdk9uAVxmc++zXLKnTNHzYN/dIHIP PAxMCXj3LWcCml5OgZ4A9h6SwrnpmLPw2e8eVxBHWQ1Jr4XnjyDgnoBqyZVxwURC+rA1 2pYFVMkV1OvaAaft6PTBxM/QaEBYhSetmuMA2TaPrzjFqCPi3dyrjSG3KOgRGGYPzLeA EygPtn/9YIZfmJTrEN1DonW5b+DM63EIg+1ExohTDI6cbtLMppUEfspn/ZbFx3zNjbb7 gLnA== X-Received: by 10.68.249.195 with SMTP id yw3mr9190987pbc.134.1397662482649; Wed, 16 Apr 2014 08:34:42 -0700 (PDT) Received: from LizhongPC ([114.62.215.53]) by mx.google.com with ESMTPSA id i10sm112621171pat.36.2014.04.16.08.34.28 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Apr 2014 08:34:40 -0700 (PDT) From: "Lizhong Jin" To: "'Stephen Kent'" , "'secdir'" , , , , , "'Adrian Farrel'" , , References: <534D9EF6.4060106@bbn.com> In-Reply-To: <534D9EF6.4060106@bbn.com> Date: Wed, 16 Apr 2014 23:34:25 +0800 Message-ID: <534ea310.ea42420a.3358.1b44@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01CF59CC.6DF29A90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9Y7l4GdVZOGcROQUCCKGujBd7mfAAksxFA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eSg2hBE5Apa8-1L8fzQWMOp5gGA Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:34:51 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ ------=_NextPart_000_0023_01CF59CC.6DF29A90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thank you for the detail review. See my reply inline below. =20 Regards Lizhong =20 From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, April 16, 2014 5:05 AM To: secdir; zhliu@gsta.com; lizho.jin@gmail.com; chen.ran@zte.com.cn; = dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; giheron@cisco.com; = nabil.n.bitar@verizon.com Subject: SECDIR review of = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 =20 I reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments = just like any other last call comments. =20 This is a very brief document, just 12 pages. The Abstract for this = document, n its entirety, says: =E2=80=9CIn many existing Virtual = Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain = connectivity has been deployed without node redundancy, or with node = redundancy in a single domain. This document describes a solution for = inter-domain VPLS based on RFC 4762 with node and link redundancy in = both domains.=E2=80=9D=20 =20 Unfortunately, this confusing wording is typical of the writing in = several areas of this document. The RFC Editor will need to work closely = with the authors to make this document easier to read. Also, there are = several instances of acronyms used without expansion (e.g., ASBR), = making reading even harder. [Lizhong] I try to rephrase the abstract below to make it more clear. I = will check again for the acronyms in detail. BTW, the ASBR has been = expanded in section 3 line 193. In many existing RFC 4762 based Virtual Private LAN Service (VPLS) = inter-domain deployments, the pseudowire (PW) connectivity has been = deployed without node redundancy, or with node redundancy only in a = single domain. That will take high risk of service interruption, since = at least one domain will not have PW node redundancy. This document = describes a inter-domain VPLS solution which could provide PW node = redundancy in both domains. =20 I like the fact that the document includes a = =E2=80=9CMotivation=E2=80=9D section. It provided a good description of = why a new approach to achieving redundancy in the VPLS context is = needed. =20 Section 5 ends with a curious statement: =20 There are two PW redundancy modes defined in [RFC6870]:=20 Independent mode and Master/Slave mode. For the inter- domain four-PW scenario, it is required for PEs to ensure that the same mode is supported on the two ICCP peers in the same RG. One method to ensure mode consistency is by manual operation. Other methods are also possible and are out of the scope of this document. =20 This says that two ASes have to ensure that both employ the same = redundancy mode choice, notes that they can verify this manually, and = that says there are other options to meet this requirement, but provides = no description of the other options. Not very useful. [Lizhong] I think the text is OK. If you insist, I could remove. Sections 5.1.1-3 provide switchover rules for redundancy. Sections 5.1.1 = and 5.1.2 both include SHOULDs, but 5.1.3 contains no analogous RFC 2119 = key words. This lack of parallelism is confusing. [Lizhong] accepted. Section 5.3 describes switchover operation in the more complex four PW = cases. It contains some RFC 2119 key words, but there are several = instances of lowercase =E2=80=9Cshould=E2=80=9D. Is this intentional? [Lizhong] I will check again, some is intentional, but some is not. The Security Considerations section is brief, only 4 short paragraphs. = It cites the Security Considerations sections of RFCs 4762 and 6870, = plus the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the = solution described here.=20 =20 RFC 4762 also contains a brief Security Considerations section, = referring the reader to RFC 4111, the PPVPN Security Framework. That = document discusses security in detail, although most of the discussion = does not appear to be directly applicable to the redundancy mechanisms = of this document. =20 RFC 6870 is directly relevant. It contains a two-sentence Security = Considerations section (almost a record for brevity?) with a lowercase = =E2=80=9Cmust=E2=80=9D for emphasis? This section refers to RFC 4447, = which contains a meaningful SC section (finally). That document mandates = use of the TCP/MD5 option for LDP. This is almost consistent with the = second paragraph of the SC section in this document (which weakens this = to a MAY), but not with the third paragraph (which seems to call for = TCP-AO). [Lizhong] RFC6870 SC is only valid for PW control plane. The second, = third and fourth paragraph is described for ICCP control plane. I will = make that clear in the text. The SC section of draft-ietf-pwe3-iccp calls for use of TCP-AO (SHOULD), = which reinforces the references in the third paragraph of this SC, but = is inconsistent with the second paragraph! =20 The second paragraph in the SC section of this document uses a = lowercase =E2=80=9Ccould.=E2=80=9D I wonder if this should be uppercase, = as per RFC 6919 J? The next paragraph directs implementers to three RFCs = (6941, 6952, and 5925), and specifically cites TCP-AO. This is confusing = guidance, given the MAY for TCP/MD5 use with LDP in the previous = paragraph. Merely calling attention to these docs is not useful = guidance.=20 The final paragraph of this section contains two obvious spelling errors = in the first sentence: =20 The activitiy on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to=20 create denial of service attackes. =20 Even if the spelling errors are corrected, it is not clear what value = this sentence adds. The remaining two sentences of the paragraph provide = useful guidance, and thus should be retained. =20 My bottom line: the SC section of this document is internally = inconsistent and conflicts with SC guidance in several of the other docs = cited in the SC section. This needs=20 =20 [Lizhong] thank you for the comments. I tend to remove the conflict = parts with [I-D.ietf-pwe3-iccp], and only describe the new security = considerations. Please help to review the following text: Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control = plane, [RFC4762] and [RFC6870] for PW control plane, this document will = have additional security consideration for ICCP control plane. =20 In this document, ICCP protocol is deployed between two PEs or ASBRs. = The two PEs or ASBRs should only be connected by a well managed and = highly monitored network. This should be ensured by the operator. =20 The state flapping on the inter-domain and intra-domain pseudowire may = cause security threats or be exploited to create denial of service = attacks. For example, excessive pseudowire state flapping (e.g., by = malicious peer PE's implementation) may lead to excessive ICCP = exchanges. Implementations SHOULD provide mechanisms to perform = control-plane policing and mitigate such types of attacks. ------=_NextPart_000_0023_01CF59CC.6DF29A90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Stephen,

Thank you for the detail review. See my reply inline = below.

 

Regards

Lizhong

 

From: Stephen Kent = [mailto:kent@bbn.com]
Sent: Wednesday, April 16, 2014 5:05 AM
To: secdir; zhliu@gsta.com; lizho.jin@gmail.com; = chen.ran@zte.com.cn; dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; giheron@cisco.com; nabil.n.bitar@verizon.com
Subject: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

 

I reviewed this document as part of the = security directorate's ongoing effort to review all IETF documents being = processed by the IESG.=C2=A0 These comments were written primarily for the benefit of = the security area directors.=C2=A0 Document editors and WG chairs should = treat these comments just like any other last call comments.

 

This is a very brief document, just 12 pages. = The Abstract for this document, n its entirety, says: =E2=80=9CIn many = existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has been deployed without node redundancy, or with node = redundancy in a single domain. This document describes a solution for inter-domain = VPLS based on RFC 4762 with node and link redundancy in both = domains.=E2=80=9D

 

Unfortunately, this confusing wording is typical = of the writing in several areas of this document. The RFC Editor will need to = work closely with the authors to make this document easier to read. Also, = there are several instances of acronyms used without expansion (e.g., ASBR), = making reading even harder.

[Lizhong] I try to rephrase the abstract below to make it = more clear. I will check again for the acronyms in detail. BTW, the ASBR has = been expanded in section 3 line 193.

In many existing RFC 4762 based Virtual Private LAN = Service (VPLS) inter-domain deployments, the pseudowire (PW) connectivity has been = deployed without node redundancy, or with node redundancy only in a single = domain. That will take high risk of service interruption, since at least one domain = will not have PW node redundancy.=C2=A0 This document describes a inter-domain = VPLS solution which could provide PW node redundancy in both = domains.

 

I like the fact that the document includes a = =E2=80=9CMotivation=E2=80=9D section. It provided a good description of why a new approach to = achieving redundancy in the VPLS context is needed.

 

Section 5 ends with a curious = statement:

=C2=A0

There are two PW redundancy modes defined in [RFC6870]:

Independent mode = and Master/Slave mode.=C2=A0 For the inter-

domain four-PW = scenario, it is required for PEs to ensure

that the same = mode is supported on the two ICCP peers in

the same = RG.=C2=A0 One method to ensure mode consistency is by

manual = operation.=C2=A0 Other methods are also possible and are

out of the scope = of this document.

 

This says that two ASes have to ensure = that both employ the same redundancy mode choice, notes that they can verify this manually, and that says there are other options to meet this = requirement, but provides no description of the other options.=C2=A0 Not very = useful.

 [Lizhong] I think the text is OK. If you insist, I could = remove.

Sections 5.1.1-3 provide switchover rules = for redundancy. Sections 5.1.1 and 5.1.2 both include SHOULDs, but 5.1.3 = contains no analogous RFC 2119 key words. This lack of parallelism is = confusing.

 [Lizhong] accepted.

Section 5.3 describes switchover operation = in the more complex four PW cases. It contains some RFC 2119 key words, but = there are several instances of lowercase =E2=80=9Cshould=E2=80=9D. Is this = intentional?

 [Lizhong] I will check again, some is intentional, but = some is not.

The Security Considerations section is = brief, only 4 short paragraphs.=C2=A0 It cites the Security Considerations sections = of RFCs 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that forms the basis of part = of the solution described here.

 

RFC 4762 also contains a brief Security Considerations section, referring the reader to RFC 4111, the PPVPN = Security Framework. That document discusses security in detail, although most of = the discussion does not appear to be directly applicable to the redundancy mechanisms of this document.

 

RFC 6870 is directly relevant. It contains = a two-sentence Security Considerations section (almost a record for = brevity?) with a lowercase =E2=80=9Cmust=E2=80=9D for emphasis? This section = refers to RFC 4447, which contains a meaningful SC section (finally). That document mandates use = of the TCP/MD5 option for LDP. This is almost consistent with the second = paragraph of the SC section in this document (which weakens this to a MAY), but not = with the third paragraph (which seems to call for TCP-AO).

 [Lizhong] RFC6870 SC is only valid for PW control plane. = The second, third and fourth paragraph is described for ICCP control plane. I will = make that clear in the text.

The SC section of draft-ietf-pwe3-iccp calls for use of TCP-AO (SHOULD), which reinforces the references in the third paragraph of this SC, but is inconsistent with the second paragraph!

 

The second paragraph in the SC = section=C2=A0 of this document uses a lowercase =E2=80=9Ccould.=E2=80=9D I wonder if this = should be uppercase, as per RFC 6919 J? The next paragraph directs implementers = to three RFCs (6941, 6952, and 5925), and specifically cites TCP-AO. This is = confusing guidance, given the MAY for TCP/MD5 use with LDP in the previous = paragraph. Merely calling attention to these docs is not useful guidance. =

The final paragraph of this section = contains two obvious spelling errors in the first sentence:

 

The = activitiy on the inter-domain and intra-domain

pseudowire may = cause security threats or be exploited to

create denial of = service attackes.

 

Even if the spelling errors are corrected, = it is not clear what value this sentence adds. The remaining two sentences of = the paragraph provide useful guidance, and thus should be = retained.

 

My bottom line: = the SC section of this document is internally inconsistent and conflicts with = SC guidance in several of the other docs cited in the SC section. This = needs

 

[Lizhong] thank you for the comments. I tend to remove = the conflict parts with [I-D.ietf-pwe3-iccp], and only describe the new = security considerations. Please help to review the following = text:

Besides the security properties of [I-D.ietf-pwe3-iccp] = for ICCP control plane, [RFC4762] and [RFC6870] for PW control plane, this = document will have additional security consideration for ICCP control = plane.

 

In this document, ICCP protocol is deployed between two = PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed = and highly monitored network. This should be ensured by the = operator.

 

The state flapping on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial = of service attacks.=C2=A0 For example, excessive pseudowire state flapping = (e.g., by malicious peer PE's implementation) may lead to excessive ICCP = exchanges. Implementations SHOULD provide mechanisms to perform control-plane = policing and mitigate such types of attacks.

------=_NextPart_000_0023_01CF59CC.6DF29A90-- From nobody Thu Apr 17 04:28:47 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29C91A0104 for ; Thu, 17 Apr 2014 04:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, 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 bdD05_3ZwDfh for ; Thu, 17 Apr 2014 04:28:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0E28B1A0090 for ; Thu, 17 Apr 2014 04:28:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.7) with ESMTP id s3HBSZNe025540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Apr 2014 14:28:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.14.7/Submit) id s3HBSZr7004598; Thu, 17 Apr 2014 14:28:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21327.47842.897728.985569@fireball.kivinen.iki.fi> Date: Thu, 17 Apr 2014 14:28:34 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BfInQAlH_0zvxzCqdhw3x0nrs7c Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 11:28:45 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Catherine Meadows is next in the rotation. For telechat 2014-04-24 Reviewer LC end Draft Dan Harkins T 2014-04-08 draft-ietf-idr-aigp-17 Charlie Kaufman T 2014-04-23 draft-ietf-precis-framework-15 Last calls and special requests: Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Phillip Hallam-Baker 2014-04-01 draft-ietf-trill-esadi-07 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2014-04-09 draft-ietf-mpls-psc-updates-03 Leif Johansson 2014-04-15 draft-ietf-ccamp-rsvp-te-eth-oam-ext-11 Scott Kelly 2014-04-18 draft-kivinen-ipsecme-ikev2-rfc5996bis-02 Tero Kivinen 2014-04-28 draft-ietf-bfd-mib-17 Warren Kumari 2014-04-28 draft-ietf-bfd-tc-mib-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-07 Ben Laurie 2014-04-25 draft-ietf-rtcweb-use-cases-and-requirements-14 Matt Lepinski 2014-04-25 draft-ietf-salud-alert-info-urns-12 Chris Lonvick 2014-04-25 draft-ietf-straw-b2bua-loop-detection-04 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Brian Weis R2014-04-30 draft-ietf-radext-dtls-10 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Apr 17 06:55:50 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017B81A016D for ; Thu, 17 Apr 2014 06:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 q8ITWbMbvFPp for ; Thu, 17 Apr 2014 06:55:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B3B391A0180 for ; Thu, 17 Apr 2014 06:55:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55113 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wammx-0006z8-3I; Thu, 17 Apr 2014 09:55:39 -0400 Message-ID: <534FDD4E.10708@bbn.com> Date: Thu, 17 Apr 2014 09:55:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lizhong Jin , 'secdir' , zhliu@gsta.com, chen.ran@zte.com.cn, dcai@cisco.com, ssalam@cisco.com, 'Adrian Farrel' , giheron@cisco.com, nabil.n.bitar@verizon.com References: <534D9EF6.4060106@bbn.com> <534ea310.ea42420a.3358.1b44@mx.google.com> In-Reply-To: <534ea310.ea42420a.3358.1b44@mx.google.com> Content-Type: multipart/alternative; boundary="------------060704020708070501060607" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ssRFGR4GAnOAe2d3fhyBeTOaX2k Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 13:55:49 -0000 This is a multi-part message in MIME format. --------------060704020708070501060607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lizhong, Thanks for the quick reply. > > Hi Stephen, > > Thank you for the detail review. See my reply inline below. > > Regards > > Lizhong > > *From:*Stephen Kent [mailto:kent@bbn.com] > *Sent:* Wednesday, April 16, 2014 5:05 AM > *To:* secdir; zhliu@gsta.com; lizho.jin@gmail.com; > chen.ran@zte.com.cn; dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; > giheron@cisco.com; nabil.n.bitar@verizon.com > *Subject:* SECDIR review of > draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 > > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This is a very brief document, just 12 pages. The Abstract for this > document, n its entirety, says: "In many existing Virtual Private LAN > Service (VPLS) deployments based on RFC 4762, inter-domain > connectivity has been deployed without node redundancy, or with node > redundancy in a single domain. This document describes a solution for > inter-domain VPLS based on RFC 4762 with node and link redundancy in > both domains." > > Unfortunately, this confusing wording is typical of the writing in > several areas of this document. The RFC Editor will need to work > closely with the authors to make this document easier to read. Also, > there are several instances of acronyms used without expansion (e.g., > ASBR), making reading even harder. > > [Lizhong] I try to rephrase the abstract below to make it more clear. > I will check again for the acronyms in detail. BTW, the ASBR has been > expanded in section 3 line 193. > The first use of ASBR is before then, I believe. The convention is to expand an acronym on first use. > > In many existing RFC 4762 based Virtual Private LAN Service (VPLS) > inter-domain deployments, the pseudowire (PW) connectivity has been > deployed without node redundancy, or with node redundancy only in a > single domain. That will take high risk of service interruption, since > at least one domain will not have PW node redundancy. This document > describes a inter-domain VPLS solution which could provide PW node > redundancy in both domains. > I think it would be clearer to say: In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no node redundancy, or offers node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PW node redundancy. This document describes an inter-domain VPLS solution that provides PW node redundancy across domains. > > I like the fact that the document includes a "Motivation" section. It > provided a good description of why a new approach to achieving > redundancy in the VPLS context is needed. > > Section 5 ends with a curious statement: > > There are two PW redundancy modes defined in [RFC6870]: > > Independent mode and Master/Slave mode. For the inter- > > domain four-PW scenario, it is required for PEs to ensure > > that the same mode is supported on the two ICCP peers in > > the same RG. One method to ensure mode consistency is by > > manual operation. Other methods are also possible and are > > out of the scope of this document. > > This says that two ASes have to ensure that both employ the same > redundancy mode choice, notes that they can verify this manually, and > that says there are other options to meet this requirement, but > provides no description of the other options. Not very useful. > > [Lizhong] I think the text is OK. If you insist, I could remove. > the text is not OK, because its states that there are multiple ways to ensure consistency, but identifies only one. > > ... > > Section 5.3 describes switchover operation in the more complex four PW > cases. It contains some RFC 2119 key words, but there are several > instances of lowercase "should". Is this intentional? > > [Lizhong] I will check again, some is intentional, but some is not. > If you are defining rules for how to achieve switchover, use of non-normative text is not of much value. > > The Security Considerations section is brief, only 4 short > paragraphs. It cites the Security Considerations sections of RFCs > 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that forms the > basis of part of the solution described here. > > RFC 4762 also contains a brief Security Considerations section, > referring the reader to RFC 4111, the PPVPN Security Framework. That > document discusses security in detail, although most of the discussion > does not appear to be directly applicable to the redundancy mechanisms > of this document. > > RFC 6870 is directly relevant. It contains a two-sentence Security > Considerations section (almost a record for brevity?) with a lowercase > "must" for emphasis? This section refers to RFC 4447, which contains a > meaningful SC section (finally). That document mandates use of the > TCP/MD5 option for LDP. This is almost consistent with the second > paragraph of the SC section in this document (which weakens this to a > MAY), but not with the third paragraph (which seems to call for TCP-AO). > > [Lizhong] RFC6870 SC is only valid for PW control plane. The second, > third and fourth paragraph is described for ICCP control plane. I will > make that clear in the text. > OK. > > ... > > [Lizhong] thank you for the comments. I tend to remove the conflict > parts with [I-D.ietf-pwe3-iccp], and only describe the new security > considerations. Please help to review the following text: > > Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP > control plane, [RFC4762] and [RFC6870] for PW control plane, this > document will have additional security consideration for ICCP control > plane. > > In this document, ICCP protocol is deployed between two PEs or ASBRs. > The two PEs or ASBRs should only be connected by a well managed and > highly monitored network. This should be ensured by the operator. > > The state flapping on the inter-domain and intra-domain pseudowire may > cause security threats or be exploited to create denial of service > attacks. For example, excessive pseudowire state flapping (e.g., by > malicious peer PE's implementation) may lead to excessive ICCP > exchanges. Implementations SHOULD provide mechanisms to perform > control-plane policing and mitigate such types of attacks. > This is clearer. Steve --------------060704020708070501060607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lizhong,

Thanks for the quick reply.

Hi Stephen,

Thank you for the detail review. See my reply inline below.

 

Regards

Lizhong

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, April 16, 2014 5:05 AM
To: secdir; zhliu@gsta.com; lizho.jin@gmail.com; chen.ran@zte.com.cn; dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; giheron@cisco.com; nabil.n.bitar@verizon.com
Subject: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

 

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This is a very brief document, just 12 pages. The Abstract for this document, n its entirety, says: “In many existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC 4762 with node and link redundancy in both domains.”

 

Unfortunately, this confusing wording is typical of the writing in several areas of this document. The RFC Editor will need to work closely with the authors to make this document easier to read. Also, there are several instances of acronyms used without expansion (e.g., ASBR), making reading even harder.

[Lizhong] I try to rephrase the abstract below to make it more clear. I will check again for the acronyms in detail. BTW, the ASBR has been expanded in section 3 line 193.

The first use of ASBR is before then, I believe.
The convention is to expand an acronym on first use.

In many existing RFC 4762 based Virtual Private LAN Service (VPLS) inter-domain deployments, the pseudowire (PW) connectivity has been deployed without node redundancy, or with node redundancy only in a single domain. That will take high risk of service interruption, since at least one domain will not have PW node redundancy.  This document describes a inter-domain VPLS solution which could provide PW node redundancy in both domains.

I think it would be clearer to say:

In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no node redundancy, or offers node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PW node redundancy. This document describes an inter-domain VPLS solution that provides PW node redundancy across domains.

 

I like the fact that the document includes a “Motivation” section. It provided a good description of why a new approach to achieving redundancy in the VPLS context is needed.

 

Section 5 ends with a curious statement:

 

There are two PW redundancy modes defined in [RFC6870]:

Independent mode and Master/Slave mode.  For the inter-

domain four-PW scenario, it is required for PEs to ensure

that the same mode is supported on the two ICCP peers in

the same RG.  One method to ensure mode consistency is by

manual operation.  Other methods are also possible and are

out of the scope of this document.

 

This says that two ASes have to ensure that both employ the same redundancy mode choice, notes that they can verify this manually, and that says there are other options to meet this requirement, but provides no description of the other options.  Not very useful.

 [Lizhong] I think the text is OK. If you insist, I could remove.

the text is not OK, because its states that there are multiple ways to ensure consistency, but  identifies only one.

...

Section 5.3 describes switchover operation in the more complex four PW cases. It contains some RFC 2119 key words, but there are several instances of lowercase “should”. Is this intentional?

 [Lizhong] I will check again, some is intentional, but some is not.

If you are defining rules for how to achieve switchover, use of non-normative text is not
of much value.

The Security Considerations section is brief, only 4 short paragraphs.  It cites the Security Considerations sections of RFCs 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the solution described here.

 

RFC 4762 also contains a brief Security Considerations section, referring the reader to RFC 4111, the PPVPN Security Framework. That document discusses security in detail, although most of the discussion does not appear to be directly applicable to the redundancy mechanisms of this document.

 

RFC 6870 is directly relevant. It contains a two-sentence Security Considerations section (almost a record for brevity?) with a lowercase “must” for emphasis? This section refers to RFC 4447, which contains a meaningful SC section (finally). That document mandates use of the TCP/MD5 option for LDP. This is almost consistent with the second paragraph of the SC section in this document (which weakens this to a MAY), but not with the third paragraph (which seems to call for TCP-AO).

 [Lizhong] RFC6870 SC is only valid for PW control plane. The second, third and fourth paragraph is described for ICCP control plane. I will make that clear in the text.

OK.

...

 

[Lizhong] thank you for the comments. I tend to remove the conflict parts with [I-D.ietf-pwe3-iccp], and only describe the new security considerations. Please help to review the following text:

Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control plane, [RFC4762] and [RFC6870] for PW control plane, this document will have additional security consideration for ICCP control plane.

 

In this document, ICCP protocol is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed and highly monitored network. This should be ensured by the operator.

 

The state flapping on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial of service attacks.  For example, excessive pseudowire state flapping (e.g., by malicious peer PE's implementation) may lead to excessive ICCP exchanges. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate such types of attacks.

This is clearer.

Steve
--------------060704020708070501060607-- From nobody Thu Apr 17 07:48:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB05B1A01E1 for ; Thu, 17 Apr 2014 07:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 JJXSOOZg5WaL for ; Thu, 17 Apr 2014 07:48:54 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 841691A01CB for ; Thu, 17 Apr 2014 07:48:54 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HEmOnU028751; Thu, 17 Apr 2014 15:48:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3HEmKdO028686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 15:48:22 +0100 From: "Adrian Farrel" To: "'Stephen Kent'" , "'Lizhong Jin'" References: <534D9EF6.4060106@bbn.com> <534ea310.ea42420a.3358.1b44@mx.google.com> <534FDD4E.10708@bbn.com> In-Reply-To: <534FDD4E.10708@bbn.com> Date: Thu, 17 Apr 2014 15:48:20 +0100 Message-ID: <042701cf5a4c$15938f00$40baad00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL2zuMx9dPTdK9hzlFlTsqb9xHflgIk566/Alol1hWYov8O0A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20640.000 X-TM-AS-Result: No--6.591-10.0-31-10 X-imss-scan-details: No--6.591-10.0-31-10 X-TMASE-MatchedRID: 24N4fKEvHsdDZFBd1jLr/uadXXcOleEbVBDQSDMig9GqvcIF1TcLYFlz o9zSKaiKlMlFOps2YVKR0KXMSioU98cUiDRLzlgWaHvuNNRsDrLTBg/CbgV2T7rfxlRjqBJ3WBo ngrY5m55Llax4oYxncBPF8Qn6QUl/ddQWHXbFHeqn1yJegn+la1AI6wCVrE3verp1WCSUvAYN/B YoxcDCEp8vpavm1fxNSvTsMFqiMb0vRbVu13x7no7Su3QulAZ5XEjKf9fhKaetj24Xqh0yXMvDQ qEdbf1NRNg+Ky3/qcV/JgN7Aw6tALVQu1GNZ+sisjvNV98mpPOh+OXJm5z8i1OENL3LvNCa7UD5 uzxVLAg54Vhi34BnRRfaB6/3nlTPftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fD_zhE5cngm7IR7LpKEW6rQO6Wc Cc: giheron@cisco.com, 'secdir' , zhliu@gsta.com, chen.ran@zte.com.cn, dcai@cisco.com, nabil.n.bitar@verizon.com, ssalam@cisco.com Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:48:57 -0000 Hello, Just pitching in on one of the points... >>> Section 5 ends with a curious statement: >>> >>> There are two PW redundancy modes defined in [RFC6870]:=20 >>> Independent mode and Master/Slave mode.=A0 For the inter- >>> domain four-PW scenario, it is required for PEs to ensure >>> that the same mode is supported on the two ICCP peers in >>> the same RG.=A0 One method to ensure mode consistency is by >>> manual operation.=A0 Other methods are also possible and are >>> out of the scope of this document. >>> >>> This says that two ASes have to ensure that both employ the >>> same redundancy mode choice, notes that they can verify >>> this manually, and that says there are other options to meet >>> this requirement, but provides no description of the other >>> options.=A0 Not very useful. >> >>=A0[Lizhong] I think the text is OK. If you insist, I could remove. > > the text is not OK, because its states that there are multiple > ways to ensure consistency, but=A0 identifies only one.=20 We had a bit of a go at this text during AD review, and I may be = responsible for it getting into this state. Previously the document just said that it was required for PEs to ensure = the same mode was in use. I insisted that some description of how this was = done was added. I don't consider manual operation to be a very good solution = (because of the likely errors that will arise), but it is undoubtedly *a* solution. I don't believe the current text says that there exist other ways of = meeting the requirement. The text uses the word "other methods are also possible" = which is inevitably true. Yet it is also the authors' contention that so long as = *a* method has been provided, other methods can be out of scope of this = document (I am sure they would be happy for people to invent new mechanisms, it's = just that they don't feel the need).=20 So, "not very useful", but not false or misleading. We could probably dilute the text to read: There are two PW redundancy modes defined in [RFC6870]:=20 Independent mode and Master/Slave mode. For the inter- domain four-PW scenario, it is required for PEs to ensure that the same mode is supported on the two ICCP peers in the same RG. This can be achieved using manual configuration at the ICCP peers. Other methods for ensuring consistency are out of the scope of this document. Thanks to you both for the work. Adrian From nobody Thu Apr 17 08:29:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477561A01DE for ; Thu, 17 Apr 2014 08:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 TM_Vv_NOaH4c for ; Thu, 17 Apr 2014 08:29:36 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 795421A015D for ; Thu, 17 Apr 2014 08:29:34 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id w10so478783pde.24 for ; Thu, 17 Apr 2014 08:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=8U6s/nmWn4yy5V7nr/j6vNGEove11D4fswIHhxexbC0=; b=MAGXF/I9hYfZWvSmEfRZPuhOCxexls4RGvZtTIGbv8E2zgx0mX0NU12nq9h+LVsMDC 7Hj5MtzafI9r6xDHrUB6fny5DxDTEGy4TqhYlF9H5zgpVtmjoWvFee+r309PqMMqfPX6 aGni3eKtP+2YWQw04UYLtLw9Y7cEzRINHH/wr0j8I7JaPhKMjkmKxtgDsCfMgtXZl7EF sCwCJBQodPku7y0vK5lB7EIg98ob/RYxJPKXebIMHC7CHZ/8cxCDwlUIiRuSBPwt6Zei vv1rhgUW2Ux7R1rAxjNJ3v9nb5Jd3Ffu39TQ/rg5UPmyf579U4Cz57ARzbqcy+yWFYnp pRHw== X-Received: by 10.68.178.131 with SMTP id cy3mr16460279pbc.146.1397748570973; Thu, 17 Apr 2014 08:29:30 -0700 (PDT) Received: from LizhongPC ([140.206.240.249]) by mx.google.com with ESMTPSA id wp3sm54192468pbc.67.2014.04.17.08.29.22 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Apr 2014 08:29:30 -0700 (PDT) From: "Lizhong Jin" To: "'Stephen Kent'" , "'secdir'" , , , , , "'Adrian Farrel'" , , References: <534D9EF6.4060106@bbn.com> <534ea310.ea42420a.3358.1b44@mx.google.com> <534FDD4E.10708@bbn.com> In-Reply-To: <534FDD4E.10708@bbn.com> Date: Thu, 17 Apr 2014 23:29:15 +0800 Message-ID: <534ff35a.63f2440a.2a54.101f@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01CF5A94.DF8A82D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac9aRLZPmwbZvW+8TQKZ2K2m8bRlagABT50g Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/614SJ2z6BFuWdCPvN-I5BYIp5vY Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:29:41 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ ------=_NextPart_000_00E7_01CF5A94.DF8A82D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Stephen, See my reply inline below. Thank you. =20 Regards Lizhong =20 =20 From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, April 17, 2014 9:55 PM To: Lizhong Jin; 'secdir'; zhliu@gsta.com; chen.ran@zte.com.cn; = dcai@cisco.com; ssalam@cisco.com; 'Adrian Farrel'; giheron@cisco.com; = nabil.n.bitar@verizon.com Subject: Re: SECDIR review of = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 =20 Lizhong, Thanks for the quick reply. Hi Stephen, Thank you for the detail review. See my reply inline below. =20 Regards Lizhong =20 From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, April 16, 2014 5:05 AM To: secdir; zhliu@gsta.com; lizho.jin@gmail.com; chen.ran@zte.com.cn; = dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; giheron@cisco.com; = nabil.n.bitar@verizon.com Subject: SECDIR review of = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 =20 I reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments = just like any other last call comments. =20 This is a very brief document, just 12 pages. The Abstract for this = document, n its entirety, says: =E2=80=9CIn many existing Virtual = Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain = connectivity has been deployed without node redundancy, or with node = redundancy in a single domain. This document describes a solution for = inter-domain VPLS based on RFC 4762 with node and link redundancy in = both domains.=E2=80=9D=20 =20 Unfortunately, this confusing wording is typical of the writing in = several areas of this document. The RFC Editor will need to work closely = with the authors to make this document easier to read. Also, there are = several instances of acronyms used without expansion (e.g., ASBR), = making reading even harder. [Lizhong] I try to rephrase the abstract below to make it more clear. I = will check again for the acronyms in detail. BTW, the ASBR has been = expanded in section 3 line 193. The first use of ASBR is before then, I believe.=20 The convention is to expand an acronym on first use. [Lizhong] I see the first use of ASBR now. Will fix it. In many existing RFC 4762 based Virtual Private LAN Service (VPLS) = inter-domain deployments, the pseudowire (PW) connectivity has been = deployed without node redundancy, or with node redundancy only in a = single domain. That will take high risk of service interruption, since = at least one domain will not have PW node redundancy. This document = describes a inter-domain VPLS solution which could provide PW node = redundancy in both domains. I think it would be clearer to say: In many existing Virtual Private LAN Service (VPLS) inter-domain = deployments (based on RFC 4762), pseudowire (PW) connectivity offers no = node redundancy, or offers node redundancy only with a single domain. = This deployment approach incurs a high risk of service interruption, = since at least one domain will not offer PW node redundancy. This = document describes an inter-domain VPLS solution that provides PW node = redundancy across domains. [Lizhong] accepted, thank you. =20 =20 I like the fact that the document includes a = =E2=80=9CMotivation=E2=80=9D section. It provided a good description of = why a new approach to achieving redundancy in the VPLS context is = needed. =20 Section 5 ends with a curious statement: =20 There are two PW redundancy modes defined in [RFC6870]:=20 Independent mode and Master/Slave mode. For the inter- domain four-PW scenario, it is required for PEs to ensure that the same mode is supported on the two ICCP peers in the same RG. One method to ensure mode consistency is by manual operation. Other methods are also possible and are out of the scope of this document. =20 This says that two ASes have to ensure that both employ the same = redundancy mode choice, notes that they can verify this manually, and = that says there are other options to meet this requirement, but provides = no description of the other options. Not very useful. [Lizhong] I think the text is OK. If you insist, I could remove. the text is not OK, because its states that there are multiple ways to = ensure consistency, but identifies only one.=20 [Lizhong] hope you are OK with Adrian=E2=80=99s proposal. =20 ...=20 Section 5.3 describes switchover operation in the more complex four PW = cases. It contains some RFC 2119 key words, but there are several = instances of lowercase =E2=80=9Cshould=E2=80=9D. Is this intentional? [Lizhong] I will check again, some is intentional, but some is not. If you are defining rules for how to achieve switchover, use of = non-normative text is not of much value. The Security Considerations section is brief, only 4 short paragraphs. = It cites the Security Considerations sections of RFCs 4762 and 6870, = plus the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the = solution described here.=20 =20 RFC 4762 also contains a brief Security Considerations section, = referring the reader to RFC 4111, the PPVPN Security Framework. That = document discusses security in detail, although most of the discussion = does not appear to be directly applicable to the redundancy mechanisms = of this document. =20 RFC 6870 is directly relevant. It contains a two-sentence Security = Considerations section (almost a record for brevity?) with a lowercase = =E2=80=9Cmust=E2=80=9D for emphasis? This section refers to RFC 4447, = which contains a meaningful SC section (finally). That document mandates = use of the TCP/MD5 option for LDP. This is almost consistent with the = second paragraph of the SC section in this document (which weakens this = to a MAY), but not with the third paragraph (which seems to call for = TCP-AO). [Lizhong] RFC6870 SC is only valid for PW control plane. The second, = third and fourth paragraph is described for ICCP control plane. I will = make that clear in the text. OK. ...=20 =20 [Lizhong] thank you for the comments. I tend to remove the conflict = parts with [I-D.ietf-pwe3-iccp], and only describe the new security = considerations. Please help to review the following text: Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control = plane, [RFC4762] and [RFC6870] for PW control plane, this document will = have additional security consideration for ICCP control plane. =20 In this document, ICCP protocol is deployed between two PEs or ASBRs. = The two PEs or ASBRs should only be connected by a well managed and = highly monitored network. This should be ensured by the operator. =20 The state flapping on the inter-domain and intra-domain pseudowire may = cause security threats or be exploited to create denial of service = attacks. For example, excessive pseudowire state flapping (e.g., by = malicious peer PE's implementation) may lead to excessive ICCP = exchanges. Implementations SHOULD provide mechanisms to perform = control-plane policing and mitigate such types of attacks. This is clearer. Steve ------=_NextPart_000_00E7_01CF5A94.DF8A82D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Stephen,

See my reply inline below. Thank = you.

 

Regards

Lizhong

 

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, April 17, 2014 9:55 PM
To: Lizhong Jin; 'secdir'; zhliu@gsta.com; chen.ran@zte.com.cn; = dcai@cisco.com; ssalam@cisco.com; 'Adrian Farrel'; giheron@cisco.com; = nabil.n.bitar@verizon.com
Subject: Re: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

 

Lizhong,


Thanks for the quick reply.

Hi Stephen,

Thank you for the detail review. See my reply inline = below.

 

Regards

Lizhong

 

From: Stephen Kent [mailto:kent@bbn.com] =
Sent: Wednesday, April 16, 2014 5:05 AM
To: secdir; zhliu@gsta.com; = lizho.jin@gmail.com; chen.ran@zte.com.cn; dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; giheron@cisco.com; nabil.n.bitar@verizon.com Subject: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

 

I reviewed this document as = part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for = the benefit of the security area directors.  Document editors and WG = chairs should treat these comments just like any other last call = comments.

 

This is a very brief = document, just 12 pages. The Abstract for this document, n its entirety, says: =E2=80=9CIn = many existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, = inter-domain connectivity has been deployed without node redundancy, or with node = redundancy in a single domain. This document describes a solution for inter-domain = VPLS based on RFC 4762 with node and link redundancy in both = domains.=E2=80=9D

 

Unfortunately, this confusing = wording is typical of the writing in several areas of this document. The RFC Editor = will need to work closely with the authors to make this document easier to = read. Also, there are several instances of acronyms used without expansion = (e.g., ASBR), making reading even harder.

[Lizhong] I try to rephrase the = abstract below to make it more clear. I will check again for the acronyms in = detail. BTW, the ASBR has been expanded in section 3 line 193.

The first use of ASBR is before = then, I believe.
The convention is to expand an acronym on first use.

[Lizhong] I see the first use of ASBR now. Will fix = it.



In many existing RFC 4762 based = Virtual Private LAN Service (VPLS) inter-domain deployments, the pseudowire (PW) connectivity has been deployed without node redundancy, or with node = redundancy only in a single domain. That will take high risk of service = interruption, since at least one domain will not have PW node redundancy.  This = document describes a inter-domain VPLS solution which could provide PW node = redundancy in both domains.

I think it would be clearer to = say:

In many existing Virtual Private LAN Service (VPLS) inter-domain = deployments (based on RFC 4762), pseudowire (PW) connectivity offers no node = redundancy, or offers node redundancy only with a single domain. This deployment = approach incurs a high risk of service interruption, since at least one domain = will not offer PW node redundancy. This document describes an inter-domain VPLS = solution that provides PW node redundancy across domains.
[Lizhong] accepted, = thank you.

 

 

I like the fact that the = document includes a =E2=80=9CMotivation=E2=80=9D section. It provided a good = description of why a new approach to achieving redundancy in the VPLS context is = needed.

 

Section 5 ends with a curious = statement:

 

There are two PW redundancy modes defined in [RFC6870]:

Independent mode and Master/Slave mode.  For the inter-

domain four-PW scenario, it is required for PEs to ensure

that the same mode is supported on the two ICCP peers in

the = same RG.  One method to ensure mode consistency is by

manual operation.  Other methods are also possible and are

out = of the scope of this document.

 

This says that two ASes have = to ensure that both employ the same redundancy mode choice, notes that they can = verify this manually, and that says there are other options to meet this = requirement, but provides no description of the other options.  Not very = useful.

 [Lizhong] I think the text = is OK. If you insist, I could remove.

the text is not OK, because its = states that there are multiple ways to ensure consistency, but  identifies only = one.
[Lizhong] hope you are = OK with Adrian=E2=80=99s proposal.

 

...

Section 5.3 describes = switchover operation in the more complex four PW cases. It contains some RFC 2119 = key words, but there are several instances of lowercase = =E2=80=9Cshould=E2=80=9D. Is this intentional?

 [Lizhong] I will check = again, some is intentional, but some is not.

If you are defining rules for = how to achieve switchover, use of non-normative text is not
of much value.

The Security Considerations = section is brief, only 4 short paragraphs.  It cites the Security = Considerations sections of RFCs 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that = forms the basis of part of the solution described here.

 

RFC 4762 also contains a = brief Security Considerations section, referring the reader to RFC 4111, the PPVPN = Security Framework. That document discusses security in detail, although most of = the discussion does not appear to be directly applicable to the redundancy mechanisms of this document.

 

RFC 6870 is directly = relevant. It contains a two-sentence Security Considerations section (almost a record for = brevity?) with a lowercase =E2=80=9Cmust=E2=80=9D for emphasis? This section = refers to RFC 4447, which contains a meaningful SC section (finally). That document mandates use = of the TCP/MD5 option for LDP. This is almost consistent with the second = paragraph of the SC section in this document (which weakens this to a MAY), but not = with the third paragraph (which seems to call for TCP-AO).

 [Lizhong] RFC6870 SC is only = valid for PW control plane. The second, third and fourth paragraph is = described for ICCP control plane. I will make that clear in the text.

OK.

...

 

[Lizhong] thank you for the comments. I tend to remove = the conflict parts with [I-D.ietf-pwe3-iccp], and only describe the new = security considerations. Please help to review the following text:

Besides the security properties of [I-D.ietf-pwe3-iccp] = for ICCP control plane, [RFC4762] and [RFC6870] for PW control plane, this = document will have additional security consideration for ICCP control = plane.

 

In this document, ICCP protocol is deployed between two = PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed = and highly monitored network. This should be ensured by the = operator.

 

The state flapping on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial = of service attacks.  For example, excessive pseudowire state flapping = (e.g., by malicious peer PE's implementation) may lead to excessive ICCP = exchanges. Implementations SHOULD provide mechanisms to perform control-plane = policing and mitigate such types of attacks.

This is clearer.

Steve

------=_NextPart_000_00E7_01CF5A94.DF8A82D0-- From nobody Thu Apr 17 09:17:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E971A0144 for ; Thu, 17 Apr 2014 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 OsF7emtM_GN4 for ; Thu, 17 Apr 2014 09:17:17 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A6E651A00FB for ; Thu, 17 Apr 2014 09:17:17 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rl12so552748iec.8 for ; Thu, 17 Apr 2014 09:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dOoTnT3jIRZyXAutwjmBJDF8nnWvYRA+yrqmcsr4frc=; b=Qw52HYqrX9EjZhHtohJ6bb93hXhnF1ct5NCY8J8v1ZZMw1EF49ZKD4rlO2yocVViTM nIGDJXZBnnqYTIW4M9ejI1k3Y+bM0833pZ7eOJfovkr0qVEyWfGl8exvl/Es0G183SvY r5kzYoM8AYnxUEOpKT/12HiwMCaNXvDs7rGfEu10h9LLkcVuXVnnWzVENop1ajI6y+Mx 7FnYqRnHb+rllQunDpugGsEte8VZ1Zbf/Nu2+2TjQqq5rQh+L8P4aYDcn/+h2AlsEz0J ahknkDTPw/fZIo4g9s4CQxD7VSnh09IMfc8g+dGdNfSg8g+f3Uq1slk7Ov4lhzDNu8/y aZWg== MIME-Version: 1.0 X-Received: by 10.42.226.8 with SMTP id iu8mr10452971icb.7.1397751434011; Thu, 17 Apr 2014 09:17:14 -0700 (PDT) Received: by 10.42.95.208 with HTTP; Thu, 17 Apr 2014 09:17:13 -0700 (PDT) In-Reply-To: <042701cf5a4c$15938f00$40baad00$@olddog.co.uk> References: <534D9EF6.4060106@bbn.com> <534ea310.ea42420a.3358.1b44@mx.google.com> <534FDD4E.10708@bbn.com> <042701cf5a4c$15938f00$40baad00$@olddog.co.uk> Date: Fri, 18 Apr 2014 00:17:13 +0800 Message-ID: From: Lizhong Jin To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=001a11c30f9eb5740504f73f5db8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/iLzOSHUihuHTVHv_ffWFaTQjeAE Cc: "giheron@cisco.com" , secdir , "zhliu@gsta.com" , "chen.ran@zte.com.cn" , "dcai@cisco.com" , "nabil.n.bitar@verizon.com" , "ssalam@cisco.com" Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:17:22 -0000 --001a11c30f9eb5740504f73f5db8 Content-Type: text/plain; charset=UTF-8 Hi Adrian, OK with the proposal. Thanks. Regards Lizhong On Thursday, April 17, 2014, Adrian Farrel wrote: > Hello, > > Just pitching in on one of the points... > > >>> Section 5 ends with a curious statement: > >>> > >>> There are two PW redundancy modes defined in [RFC6870]: > >>> Independent mode and Master/Slave mode. For the inter- > >>> domain four-PW scenario, it is required for PEs to ensure > >>> that the same mode is supported on the two ICCP peers in > >>> the same RG. One method to ensure mode consistency is by > >>> manual operation. Other methods are also possible and are > >>> out of the scope of this document. > >>> > >>> This says that two ASes have to ensure that both employ the > >>> same redundancy mode choice, notes that they can verify > >>> this manually, and that says there are other options to meet > >>> this requirement, but provides no description of the other > >>> options. Not very useful. > >> > >> [Lizhong] I think the text is OK. If you insist, I could remove. > > > > the text is not OK, because its states that there are multiple > > ways to ensure consistency, but identifies only one. > > We had a bit of a go at this text during AD review, and I may be > responsible for > it getting into this state. > > Previously the document just said that it was required for PEs to ensure > the > same mode was in use. I insisted that some description of how this was > done was > added. I don't consider manual operation to be a very good solution > (because of > the likely errors that will arise), but it is undoubtedly *a* solution. > > I don't believe the current text says that there exist other ways of > meeting the > requirement. The text uses the word "other methods are also possible" > which is > inevitably true. Yet it is also the authors' contention that so long as *a* > method has been provided, other methods can be out of scope of this > document (I > am sure they would be happy for people to invent new mechanisms, it's just > that > they don't feel the need). > > So, "not very useful", but not false or misleading. > > We could probably dilute the text to read: > > There are two PW redundancy modes defined in [RFC6870]: > Independent mode and Master/Slave mode. For the inter- > domain four-PW scenario, it is required for PEs to ensure > that the same mode is supported on the two ICCP peers in > the same RG. This can be achieved using manual configuration > at the ICCP peers. Other methods for ensuring consistency are > out of the scope of this document. > > Thanks to you both for the work. > > Adrian > > --001a11c30f9eb5740504f73f5db8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adrian,
OK with the proposal. Thanks.

Regar= ds
Lizhong

On Thursday, April 17, 2014, Adrian Farrel <= adrian@olddog.co.uk> wrote:
Hello,

Just pitching in on one of the points...

>>> Section 5 ends with a curious statement:
>>>
>>> =C2=A0There are two PW redundancy modes defined in [RFC6870]:<= br> >>> =C2=A0Independent mode and Master/Slave mode.=C2=A0 For the in= ter-
>>> =C2=A0domain four-PW scenario, it is required for PEs to ensur= e
>>> =C2=A0that the same mode is supported on the two ICCP peers in=
>>> =C2=A0the same RG.=C2=A0 One method to ensure mode consistency= is by
>>> =C2=A0manual operation.=C2=A0 Other methods are also possible = and are
>>> =C2=A0out of the scope of this document.
>>>
>>> This says that two ASes have to ensure that both employ the >>> same redundancy mode choice, notes that they can verify
>>> this manually, and that says there are other options to meet >>> this requirement, but provides no description of the other
>>> options.=C2=A0 Not very useful.
>>
>>=C2=A0[Lizhong] I think the text is OK. If you insist, I could remo= ve.
>
> the text is not OK, because its states that there are multiple
> ways to ensure consistency, but=C2=A0 identifies only one.

We had a bit of a go at this text during AD review, and I may be responsibl= e for
it getting into this state.

Previously the document just said that it was required for PEs to ensure th= e
same mode was in use. I insisted that some description of how this was done= was
added. I don't consider manual operation to be a very good solution (be= cause of
the likely errors that will arise), but it is undoubtedly *a* solution.

I don't believe the current text says that there exist other ways of me= eting the
requirement. The text uses the word "other methods are also possible&q= uot; which is
inevitably true. Yet it is also the authors' contention that so long as= *a*
method has been provided, other methods can be out of scope of this documen= t (I
am sure they would be happy for people to invent new mechanisms, it's j= ust that
they don't feel the need).

So, "not very useful", but not false or misleading.

We could probably dilute the text to read:

=C2=A0 There are two PW redundancy modes defined in [RFC6870]:
=C2=A0 Independent mode and Master/Slave mode. =C2=A0For the inter-
=C2=A0 domain four-PW scenario, it is required for PEs to ensure
=C2=A0 that the same mode is supported on the two ICCP peers in
=C2=A0 the same RG. =C2=A0This can be achieved using manual configuration =C2=A0 at the ICCP peers. Other methods for ensuring consistency are
=C2=A0 out of the scope of this document.

Thanks to you both for the work.

Adrian

--001a11c30f9eb5740504f73f5db8-- From nobody Fri Apr 18 06:50:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDF71A0250 for ; Fri, 18 Apr 2014 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 UmwrKpZe_CsP for ; Fri, 18 Apr 2014 06:50:36 -0700 (PDT) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) by ietfa.amsl.com (Postfix) with ESMTP id 887491A024B for ; Fri, 18 Apr 2014 06:50:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 80ED22E80B9; Fri, 18 Apr 2014 09:50:32 -0400 (EDT) X-Virus-Scanned: OK Received: from app6.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 66E532E80B7; Fri, 18 Apr 2014 09:50:32 -0400 (EDT) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app6.wa-webapps.iad3a (Postfix) with ESMTP id 5359280059; Fri, 18 Apr 2014 09:50:32 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 18 Apr 2014 06:50:32 -0700 (PDT) Date: Fri, 18 Apr 2014 06:50:32 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-kivinen-ipsecme-ikev2-rfc5996bis.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1397829032.33926049@apps.rackspace.com> X-Mailer: webmail7.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Us4t1JWZUaFxzSi6wOnaEnaJZUE Subject: [secdir] secdir review of draft-kivinen-ipsecme-ikev2-rfc5996bis-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 13:50:37 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThis is an update to RFC5996 (IKEv2). From= the document, it makes the following changes:=0A=0A Fixed section 3.6 an= d 3.10 as specified in the RFC5996 errata 2707=0A and 3036.=0A=0A Remov= ed Raw RSA Public keys. There is new work ongoing to replace=0A that wit= h more generic format for generic raw public keys.=0A=0A Added reference = to the RFC6989 when using non Sophie-Germain Diffie-=0A Hellman groups, o= r when reusing Diffie-Hellman Exponentials.=0A=0A Added reference to the = RFC4945 in the Identification Payloads=0A section.=0A=0A Added IANA Con= siderations section note about removing the Raw RSA=0A Key, and removed t= he old contents which was already done during=0A RFC5996 processing. Add= ed note that IANA should update IKEv2=0A registry to point to this docume= nt instead of RFC5996.=0A=0A Clarified that the intended status of this d= ocument is Internet=0A Standard both in abstract and Introduction section= .=0A=0A Added name Last Substruc for the Proposal and Transform Substruct= ure=0A header for the 0 (last) or 2/3 (more) field.=0A=0ABased on the wel= l known and well respected collection of authors, I think it is safe to con= clude that ample consideration has been given to all things security in thi= s one. I see nothing in the above list that makes me think otherwise.=0A=0A= --Scott=0A From nobody Fri Apr 18 16:02:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC51A01F0; Fri, 18 Apr 2014 15:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 5NrQtgizffqX; Fri, 18 Apr 2014 15:58:42 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 756771A01B5; Fri, 18 Apr 2014 15:58:42 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md12so1869032pbc.35 for ; Fri, 18 Apr 2014 15:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=L73IoCi4E7GQ+MunKwnpH9COx+Zn3CgE/RKvnx7UtW8=; b=qC7BFRHalJ7M5Rf+eA+kjrYtrMy8WGpeofyWdiIQ4uFucIcxvgrCWWROXRNGh1pZ5c a+kVYJYPO1AuFIaCZamGOC62RJlWbHLyIVDpFSotgnCgOztjtG3QVCgLN1vsmnFy775K JuYrIxY+nhahgXb3fxynM18ld2g32enOCQe112wB/ymeH/mBmsQmGsjtaGnpzegWGAGj wxLXFunJ/vzliG7PmZyrxG0tFNjeTcWHeHQWJRQoIAKMNIOibMu5N7sFVQvVReV16NMd 9ZFeLXPaW6fbHi1FIdHWXMIIoHRC+caAEAjndTDG75O70C0nlq0uGhvWvEod5oPDRRqb C11A== X-Received: by 10.66.252.135 with SMTP id zs7mr24532699pac.13.1397861918525; Fri, 18 Apr 2014 15:58:38 -0700 (PDT) Received: from [10.19.75.99] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id ba5sm62090748pbc.61.2014.04.18.15.58.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 15:58:37 -0700 (PDT) Message-ID: <5351AE1C.1000603@gmail.com> Date: Fri, 18 Apr 2014 15:58:36 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: draft-ietf-straw-b2bua-loop-detection@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="------------090606000707040406090204" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MQnsdzhs-qGNHQbrG7sgmtjSJRw X-Mailman-Approved-At: Fri, 18 Apr 2014 16:02:31 -0700 Subject: [secdir] SECDIR review of draft-ietf-straw-b2bua-loop-detection-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 22:58:43 -0000 This is a multi-part message in MIME format. --------------090606000707040406090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is well written and I agree that the Security Considerations section of RFC 5393 pretty much covers everything in this document. I don't feel strongly about this\, but the authors may wish to describe what could happen if one B2BUA adheres to the specifications described in this document (adds appropriate header information when it finds none) and an old B2BUA that has not implemented these specifications (may strip out Via header information) causing a loop to encourage everyone to implement the recommendations in this specification. Regards, Chris --------------090606000707040406090204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

 
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document is well written and I agree that the Security Considerations 
section of RFC 5393 pretty much covers everything in this document.

I don't feel strongly about this\, but the authors may wish to describe 
what could happen if one B2BUA adheres to the specifications described in 
this document (adds appropriate header information when it finds none) 
and an old B2BUA that has not implemented these specifications (may strip 
out Via header information) causing a loop to encourage everyone to
implement the recommendations in this specification.

Regards,
Chris
--------------090606000707040406090204-- From nobody Sat Apr 19 22:37:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32681A0138; Sat, 19 Apr 2014 22:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 dVnBsS8KdQjX; Sat, 19 Apr 2014 22:37:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7821C1A0137; Sat, 19 Apr 2014 22:37:25 -0700 (PDT) Received: from BL2PR03MB498.namprd03.prod.outlook.com (10.141.93.146) by BL2PR03MB500.namprd03.prod.outlook.com (10.141.93.152) with Microsoft SMTP Server (TLS) id 15.0.918.8; Sun, 20 Apr 2014 05:37:19 +0000 Received: from BL2PR03MB498.namprd03.prod.outlook.com ([10.141.93.146]) by BL2PR03MB498.namprd03.prod.outlook.com ([10.141.93.146]) with mapi id 15.00.0918.000; Sun, 20 Apr 2014 05:37:19 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-precis-framework.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-precis-framework-15 Thread-Index: Ac9cUaZDabIX9cuLSHKrDHLDynyVYw== Date: Sun, 20 Apr 2014 05:37:18 +0000 Message-ID: <23eaf4c7da5a4bbe94c9f00496716596@BL2PR03MB498.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.158.7] x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(16601075003)(99286001)(80976001)(99396002)(81542001)(33646001)(76576001)(83322001)(19300405004)(19580395003)(46102001)(4396001)(74316001)(76482001)(15202345003)(16236675002)(77096999)(54356999)(50986999)(66066001)(81342001)(77982001)(79102001)(20776003)(2201001)(15975445006)(86612001)(31966008)(80022001)(2656002)(74502001)(83072002)(86362001)(92566001)(87936001)(74662001)(85852003)(551544002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB500; H:BL2PR03MB498.namprd03.prod.outlook.com; FPR:FEC7D14D.A70A9550.B1D716BB.8AE9F061.2054F; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_23eaf4c7da5a4bbe94c9f00496716596BL2PR03MB498namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/XVs53_mINAAALjcfFObWzgbjsIo Subject: [secdir] secdir review of draft-ietf-precis-framework-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 05:37:30 -0000 --_000_23eaf4c7da5a4bbe94c9f00496716596BL2PR03MB498namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document concerns international character sets. You might intuitively = think that international character sets would have few if any security cons= iderations, but you would be wrong. Many security mechanisms depend on the = ability to recognize that two identifiers refer to the same entity and inco= nsistent handling of international character sets can result in two differe= nt pieces of code disagreeing as to whether two identifiers match and this = has led to a number of serious security problems. This document defines 18 categories of characters within the UNICODE charac= ter set, with the intention that systems that want to accept subsets of UNI= CODE characters in their identifiers specify profiles referencing this docu= ment, and it defines two initial classes (IdentifierClass and FreeformClass= ) that could be used directly by lots of protocol specifications. While I see no problems with this document, it does seem like a missed oppo= rtunity to specify some things that are very important in the secure use of= international character sets. The most important of these is a rule for de= termining whether two strings should be considered to be equivalent. It is = very common in both IETF protocols and in operating system object naming to= adopt a preserve case / ignore case model. That means that if an identifie= r is entered in mixed case, the mixed case is preserved as the identifier b= ut if someone tries to find an object using an identifier that is identical= except for the case of characters, it will find the object. Further, in in= stances where uniqueness of identifiers is enforced (e.g. user names or fil= e names), a request to create a second identifier that differs only in the = case of the characters from an existing one will fail. These scenarios require that if be well defined whether two characters diff= er only in case, and while that is an easy check to make in ASCII with 26 l= etters that have upper and lower case versions, the story is much more comp= lex for some international character sets. Worse, case mapping of even ASCI= I characters can change based on the "culture". The most famous example is = the Turkish undotted lower case 'i' and uppercase dotted 'I' which caused s= ecurity bugs because mapping "FILE" to lowercase in the Turkish Locale did = not result in the string "file". There are also cases where two different l= owercase characters are both mapped to the same uppercase character. It is = a scary world out there. To be used safely from a security standpoint, there must be a standardized = way to compare two strings for equivalence that all programs will agree on.= Programs will still have bugs, but when two programs interpret equivalence= differently it is important that it be possible to determine objectively w= hich one is wrong. The ideal way to do this is to have a canonical form of = any string such that two strings are equivalent if their canonical forms ar= e identical. Section "10.4 Local Character Set Issues" acknowledges this problem, but of= fers no solution. In section "10.6 Security of Passwords", this document recommends that pass= word comparisons not ignore case (and I agree). But for passwords in partic= ular, it is vital that they be translated to a canonical form because they = are frequently hashed and the hashes must test as identical. One rarely has= the luxury of comparing passwords character by character and deciding whet= her the characters are "close enough". Section "10.5 Visually Similar Characters" discusses another hard problem: = characters that are entirely distinct but are visually similar enough to mi= slead users. This problem occurs even without leaving ASCII in the form of = the digit '0' vs the uppercase letter 'O' and triple of the digit '1', the = lowercase letter 'l', and the uppercase letter 'I'. In some fonts, various = of these are indistinguishable. International character sets introduce even= more such collisions. To the extent that we expect users to look at URLs l= ike https://www.fideIity.com and recognize that so= mething is out of place, we have a problem. It is probably best addressed b= y having tables of "looks similar" characters and disallowing the issuance = of identifiers that look visually similar to existing ones in places like D= NS registries and other places where this problem arises. Having a document= that lists the doppelganger character equivalents would be a useful first = step towards deploying such restrictions. I suppose it is too much to expect this document to address either of these= issues, but I couldn't resist suggesting it. --Charlie --_000_23eaf4c7da5a4bbe94c9f00496716596BL2PR03MB498namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t of the security area directors.  Document editors and WG chairs should treat these comments just like any other last= call comments.

 

This document concerns international character sets.= You might intuitively think that international character sets would have f= ew if any security considerations, but you would be wrong. Many security me= chanisms depend on the ability to recognize that two identifiers refer to the same entity and inconsistent h= andling of international character sets can result in two different pieces = of code disagreeing as to whether two identifiers match and this has led to= a number of serious security problems.

 

This document defines 18 categories of characters wi= thin the UNICODE character set, with the intention that systems that want t= o accept subsets of UNICODE characters in their identifiers specify profile= s referencing this document, and it defines two initial classes (IdentifierClass and FreeformClass) that could= be used directly by lots of protocol specifications.

 

While I see no problems with this document, it does = seem like a missed opportunity to specify some things that are very importa= nt in the secure use of international character sets. The most important of= these is a rule for determining whether two strings should be considered to be equivalent. It is very common in bo= th IETF protocols and in operating system object naming to adopt a preserve= case / ignore case model. That means that if an identifier is entered in m= ixed case, the mixed case is preserved as the identifier but if someone tries to find an object using an identifi= er that is identical except for the case of characters, it will find the ob= ject. Further, in instances where uniqueness of identifiers is enforced (e.= g. user names or file names), a request to create a second identifier that differs only in the case of the= characters from an existing one will fail.

 

These scenarios require that if be well defined whet= her two characters differ only in case, and while that is an easy check to = make in ASCII with 26 letters that have upper and lower case versions, the = story is much more complex for some international character sets. Worse, case mapping of even ASCII characters= can change based on the “culture”. The most famous example is = the Turkish undotted lower case ‘i’ and uppercase dotted ‘= ;I’ which caused security bugs because mapping “FILE” to = lowercase in the Turkish Locale did not result in the string “file”. The= re are also cases where two different lowercase characters are both mapped = to the same uppercase character. It is a scary world out there.<= /p>

 

To be used safely from a security standpoint, there = must be a standardized way to compare two strings for equivalence that all = programs will agree on. Programs will still have bugs, but when two program= s interpret equivalence differently it is important that it be possible to determine objectively which one is = wrong. The ideal way to do this is to have a canonical form of any string s= uch that two strings are equivalent if their canonical forms are identical.=

 

Section “10.4 Local Character Set Issues”= ; acknowledges this problem, but offers no solution.

 

In section “10.6 Security of Passwords”,= this document recommends that password comparisons not ignore case (and I = agree). But for passwords in particular, it is vital that they be translate= d to a canonical form because they are frequently hashed and the hashes must test as identical. One rarely has the luxury of= comparing passwords character by character and deciding whether the charac= ters are “close enough”.

 

Section “10.5 Visually Similar Characters̶= 1; discusses another hard problem: characters that are entirely distinct bu= t are visually similar enough to mislead users. This problem occurs even wi= thout leaving ASCII in the form of the digit ‘0’ vs the uppercase letter ‘O’ and triple of the digit ‘1&#= 8217;, the lowercase letter ‘l’, and the uppercase letter ̵= 6;I’. In some fonts, various of these are indistinguishable. Internat= ional character sets introduce even more such collisions. To the extent tha= t we expect users to look at URLs like https://www.fideIity.com and recognize that something is out of place, we h= ave a problem. It is probably best addressed by having tables of “loo= ks similar” characters and disallowing the issuance of identifiers that look visually similar to existing ones in pla= ces like DNS registries and other places where this problem arises. Having = a document that lists the doppelganger character equivalents would be a use= ful first step towards deploying such restrictions.

 

I suppose it is too much to expect this document to = address either of these issues, but I couldn’t resist suggesting it.<= o:p>

 

        &nbs= p;       --Charlie

--_000_23eaf4c7da5a4bbe94c9f00496716596BL2PR03MB498namprd03pro_-- From nobody Mon Apr 21 07:40:34 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91D51A021D; Mon, 21 Apr 2014 07:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.174 X-Spam-Level: X-Spam-Status: No, score=-4.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-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 K27B75mxovBa; Mon, 21 Apr 2014 07:40:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 41C621A021F; Mon, 21 Apr 2014 07:40:28 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C3F2A4032A; Mon, 21 Apr 2014 08:40:18 -0600 (MDT) Message-ID: <53552DD4.4080801@stpeter.im> Date: Mon, 21 Apr 2014 08:40:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Charlie Kaufman , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-precis-framework.all@tools.ietf.org" References: <23eaf4c7da5a4bbe94c9f00496716596@BL2PR03MB498.namprd03.prod.outlook.com> In-Reply-To: <23eaf4c7da5a4bbe94c9f00496716596@BL2PR03MB498.namprd03.prod.outlook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/iMU65C5MbYct9j1OBDn3g_hteic Subject: Re: [secdir] secdir review of draft-ietf-precis-framework-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 14:40:33 -0000 Thanks for the review. Comments and proposed text inline. On 4/19/14, 11:37 PM, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document concerns international character sets. You might > intuitively think that international character sets would have few if > any security considerations, but you would be wrong. Many security > mechanisms depend on the ability to recognize that two identifiers refer > to the same entity and inconsistent handling of international character > sets can result in two different pieces of code disagreeing as to > whether two identifiers match and this has led to a number of serious > security problems. > > This document defines 18 categories of characters within the UNICODE > character set, with the intention that systems that want to accept > subsets of UNICODE characters in their identifiers specify profiles > referencing this document, and it defines two initial classes > (IdentifierClass and FreeformClass) that could be used directly by lots > of protocol specifications. > > While I see no problems with this document, it does seem like a missed > opportunity to specify some things that are very important in the secure > use of international character sets. The most important of these is a > rule for determining whether two strings should be considered to be > equivalent. What we have here is a failure to communicate. :-) The purpose of the PRECIS work is twofold: 1. determine if a given string is allowed 2. determine if two given strings are equivalent Since that it not stated clearly enough in the document, we need to add some text. I propose the following change to the Introduction: ### OLD ... Profiles are responsible for defining the handling of right-to-left characters as well as various mapping operations of the kind also discussed for IDNs in [RFC5895], such as case preservation or lowercasing, Unicode normalization, mapping of certain characters to other characters or to nothing, and mapping of full-width and half-width characters. It is expected that this framework will yield the following benefits: NEW ... Profiles are responsible for defining the handling of right-to-left characters as well as various mapping operations of the kind also discussed for IDNs in [RFC5895], such as case preservation or lowercasing, Unicode normalization, mapping of certain characters to other characters or to nothing, and mapping of full-width and half-width characters. When an application applies a profile of a PRECIS string class, it can achieve the following objectives: a. Determine if a given string conforms to the profile (e.g. to determine if it is allowed for use in the relevant "slot" specified by an application protocol). b. Determine if any two given strings are equivalent (e.g., to make an access decision for purposes of authentication or authorization as further described in [RFC6943]). It is expected that this framework will yield the following benefits: ### The PRECIS framework document contains no examples. However, all of the existing profile documents contain examples: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-4.3 http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-5.3 http://tools.ietf.org/html/draft-ietf-precis-nickname-09#section-3 http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-3.5 I'm a big believer in examples, so I suggest that we add some to the framework document, or at least point specifically to the relevant sections of those profile documents. > It is very common in both IETF protocols and in operating > system object naming to adopt a preserve case / ignore case model. That > means that if an identifier is entered in mixed case, the mixed case is > preserved as the identifier but if someone tries to find an object using > an identifier that is identical except for the case of characters, it > will find the object. Further, in instances where uniqueness of > identifiers is enforced (e.g. user names or file names), a request to > create a second identifier that differs only in the case of the > characters from an existing one will fail. > > These scenarios require that if be well defined whether two characters > differ only in case, This is handled in PRECIS profile definitions by specifying case mapping. As we have defined the framework, that is a matter for profiles, not the base string classes. > and while that is an easy check to make in ASCII > with 26 letters that have upper and lower case versions, the story is > much more complex for some international character sets. Worse, case > mapping of even ASCII characters can change based on the “culture”. The > most famous example is the Turkish undotted lower case ‘i’ and uppercase > dotted ‘I’ which caused security bugs because mapping “FILE” to > lowercase in the Turkish Locale did not result in the string “file”. > There are also cases where two different lowercase characters are both > mapped to the same uppercase character. It is a scary world out there. > > To be used safely from a security standpoint, there must be a > standardized way to compare two strings for equivalence that all > programs will agree on. Programs will still have bugs, but when two > programs interpret equivalence differently it is important that it be > possible to determine objectively which one is wrong. The ideal way to > do this is to have a canonical form of any string such that two strings > are equivalent if their canonical forms are identical. > > Section “10.4 Local Character Set Issues” acknowledges this problem, but > offers no solution. Actually, Section 10.4 discusses the problem of character encodings other than ASCII and Unicode (say, "Shift JIS" in Japan). Localization issues (such as Turkish dotless "i") are discussed further in draft-ietf-precis-mappings. They are not addressed in the PRECIS framework because we could solve only so many problems in the framework and the working group decided to limit itself to internationalization, not also localization. > In section “10.6 Security of Passwords”, this document recommends that > password comparisons not ignore case (and I agree). But for passwords in > particular, it is vital that they be translated to a canonical form > because they are frequently hashed and the hashes must test as > identical. One rarely has the luxury of comparing passwords character by > character and deciding whether the characters are “close enough”. Indeed. This is discussed in draft-ietf-precis-saslprepbis (which does define a PRECIS profile for passwords). Would it help to point to that document here? > Section “10.5 Visually Similar Characters” discusses another hard > problem: characters that are entirely distinct but are visually similar > enough to mislead users. This problem occurs even without leaving ASCII > in the form of the digit ‘0’ vs the uppercase letter ‘O’ and triple of > the digit ‘1’, the lowercase letter ‘l’, and the uppercase letter ‘I’. > In some fonts, various of these are indistinguishable. International > character sets introduce even more such collisions. To the extent that > we expect users to look at URLs like https://www.fideIity.com > and recognize that something is out of place, > we have a problem. It is probably best addressed by having tables of > “looks similar” characters and disallowing the issuance of identifiers > that look visually similar to existing ones in places like DNS > registries and other places where this problem arises. Having a document > that lists the doppelganger character equivalents would be a useful > first step towards deploying such restrictions. The Unicode Consortium maintains such a document: http://www.unicode.org/Public/security/latest/confusables.txt > I suppose it is too much to expect this document to address either of > these issues, but I couldn’t resist suggesting it. What we are talking about here is really a matter of scope. There is only so much that we could accomplish in the PRECIS framework itself. In particular, issues of localization and confusability are extremely messy and trying to tackle them would have significantly delayed our work. Peter From nobody Mon Apr 21 12:24:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6848F1A0277 for ; Mon, 21 Apr 2014 12:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 uUDUUzhZ347X for ; Mon, 21 Apr 2014 12:24:26 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9BC1A0254 for ; Mon, 21 Apr 2014 12:24:25 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3LJOANS009395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2014 15:24:10 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s3LJOANS009395 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1398108252; bh=CmNzp+QlE/KrTvZNHBYblbUG798=; h=From:To:CC:Date:Subject:Message-ID:Content-Type:MIME-Version; b=qD102oRLp439HbHsbawvpEDrL8LyvCpsC27c9rFEPcYEwlrJcj1sE6sLRCmg9mrgz G+3pWJ1ISSNYmRNRuYsq7oHPeqHnp3i6vc0QV0TyyOGgC73FuvKVuINUJiPW8mUSn+ EY2wHi7B44Lj1HtYuWqrlYALkgcWD+IR1x8SATkU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s3LJOANS009395 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 21 Apr 2014 15:23:49 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3LJNm1Y010156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 15:23:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub36.corp.emc.com ([::1]) with mapi; Mon, 21 Apr 2014 15:23:48 -0400 From: "Moriarty, Kathleen" To: "secdir@ietf.org" Date: Mon, 21 Apr 2014 15:23:46 -0400 Thread-Topic: Errata - looking for volunteers Thread-Index: Ac9dloR1NA2cKhSWQJql/+IKDwhvtA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24102766B81DMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Kc2Oph0073OcuP3f39mlfi3b7w0 Cc: "kathleen.moriarty.ietf@gmail.com" Subject: [secdir] Errata - looking for volunteers X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:24:28 -0000 --_000_F5063677821E3B4F81ACFB7905573F24102766B81DMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Stephen and I would like to see if any of the SecDir members would be inter= ested to help us get through the outstanding errata for security related RF= Cs. We have a bit of a backlog and could use some help. Some will be fair= ly easy to address and others will take a bit more time. 1. The errata reviewer would figure out the disposition however you w= ant (we'll give you some guidelines to follow), 2. Mail relevant IETF lists, WG or not, then 3. Send a mail to secdir with your proposed disposition and then go h= it the buttons to address the filed errata The help on reviews is invaluable and this would be as well! You can priva= te message us if interested. Thank you, Kathleen & Stephen --_000_F5063677821E3B4F81ACFB7905573F24102766B81DMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Stephen= and I would like to see if any of the SecDir members would be interested t= o help us get through the outstanding errata for security related RFCs.&nbs= p; We have a bit of a backlog and could use some help.  Some will be f= airly easy to address and others will take a bit more time.

<= p class=3DMsoPlainText> 

1.       The errata reviewer would figure out the disposition however you want (we&= #8217;ll give you some guidelines to follow),

2.       <= /span>Mail relevant IETF lists, WG or not, then

3.     &nb= sp; Send a mail to secdir with your proposed dispos= ition and then go hit the buttons to address the filed errata

 

The h= elp on reviews is invaluable and this would be as well!  You can priva= te message us if interested.

&nb= sp;

Thank you,

Kathleen & Stephen

&= nbsp;

= --_000_F5063677821E3B4F81ACFB7905573F24102766B81DMX15Acorpemcc_-- From nobody Wed Apr 23 14:53:48 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 871861A002A; Mon, 21 Apr 2014 20:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1398136395; bh=ilGskV9qaTbN2yZZiCveIjAfzuKLuwcqPS0QWKqCBXY=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=BXPLv43LaqRxBVlKjkckvMQ+347kPQ4NbmUJe6daibJUCEq20h6vsrGm6VCbtkzGM TIxFA8EqW8TODbqFdwF28FWGX9dONi/A1YZzAvqCk+9H9CGYcAsgqMLcomyLQcS7sK X88nc3iIJqN0QGwWvoFIUEfGge+7+BgAbQn2pdc0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD041A002A for ; Mon, 21 Apr 2014 20:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.772 X-Spam-Level: X-Spam-Status: No, score=-3.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 Ff1zSP_7cTPH for ; Mon, 21 Apr 2014 20:13:03 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4578D1A0027 for ; Mon, 21 Apr 2014 20:13:02 -0700 (PDT) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="4.97,900,1389765600"; d="scan'208,217";a="487078540" From: To: Date: Mon, 21 Apr 2014 22:12:55 -0500 Thread-Topic: IEEE 802 March 2014 Plenary - New Study Groups Thread-Index: Ac9d2LLwi4k+vevLQp2G40sLvK+OEA== Message-ID: <28616F4740DDF542AA1DB7C9F597963907AD48AF57@AUSX7MCPS301.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/CvfPaL7PyhxPXBX0MQOZWisLLQo X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: multipart/mixed; boundary="===============7643709485623123333==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wO87Te--fz4LhThDIPFFCan65eQ X-Mailman-Approved-At: Wed, 23 Apr 2014 14:53:47 -0700 Cc: p.nikolich@ieee.org Subject: [secdir] [new-work] IEEE 802 March 2014 Plenary - New Study Groups X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 03:13:15 -0000 --===============7643709485623123333== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_28616F4740DDF542AA1DB7C9F597963907AD48AF57AUSX7MCPS301A_" --_000_28616F4740DDF542AA1DB7C9F597963907AD48AF57AUSX7MCPS301A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Members of the IETF, In the spirit of continuing cooperation between IEEE 802 and IETF, the foll= owing letter addresses new work items for information and potential coordin= ation with the respective IEEE 802 WG. One of the first steps in the IEEE Standards Association's standards develo= pment process is the creation of a Study Group. Study groups are chartered = to create a formal Project Authorization Request (PAR) document that includ= es a description of the project's scope and purpose. The following Study Groups were approved at the Mar 2014 IEEE 802 Plenary - * IEEE 802.3 Gigabit Plastic Optical Fibre (POF) Study Group * IEEE 802.3 100 Mb/s Operation over a Single Twisted Pair Study Gr= oup Further information about these Study Groups may be found at http://www.iee= e802.org/StudyGroups.shtml. Please note, per the IEEE 802 Policies and Procedures that a Study Group is= chartered to operate until the next plenary session, a period of four mont= hs and, if it wishes to continue, must request a charter extension. Study G= roups may also terminate between plenary sessions if their proposed project= is approved by the IEEE Standards Association Standards Board. Additionally, within the IEEE 802 family of standards, there is a requireme= nt that each new project proposal attaches additional documentation that de= scribes its engineering feasibility, market potential, assurance of coexist= ence and distinct identity relative to previous standards (referred to as t= he "CSD" in 802, which also includes the "5 criteria"). The "Criteria for S= tandards Development (CSD)" used by IEEE 802 can be found in document: https://mentor.ieee.org/802-ec/dcn/14/ec-14-0028-00-00EC-csd-informative-e= xtract.pdf Also please note that IEEE meetings are open and may be attended by any ind= ividuals who register and fulfill any registration fees. Details regarding = future IEEE 802 plenary meeting schedules may be found at http://802world.o= rg/plenary/future-plenary-sessions/. Please refer to individual working g= roups for their interim meeting schedules. A listing of all working groups = may be found at http://www.ieee802.org/. Sincerely, John D'Ambrosia Recording Secretary, IEEE 802 LMSC jdambrosia@ieee.org --_000_28616F4740DDF542AA1DB7C9F597963907AD48AF57AUSX7MCPS301A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Members of = the IETF,

In the spirit = of continuing cooperation between IEEE 802 and IETF, the following letter a= ddresses new work items for information and potential coordination with the= respective IEEE 802 WG.

One of the first steps in the IEEE Standards Association’s st= andards development process is the creation of a Study Group. Study groups = are chartered to create a formal Project Authorization Request (PAR) docume= nt that includes a description of the project’s scope and purpose.

The following Stud= y Groups were approved at the Mar 2014 IEEE 802 Plenary – =

 

·&= nbsp;        IEEE = 802.3 Gigabit Plastic Optical Fibre (POF) Study Group

=

·         IEEE 802.3 100 Mb/s Operation over a Single Twisted Pair = Study Group

Furth= er information about these Study Groups may be found at http://www.ieee802.org/StudyGroups.shtml.=   

Ple= ase note, per the IEEE 802 Policies and Procedures that a Study Group is ch= artered to operate until the next plenary session, a period of four months = and, if it wishes to continue, must request a charter extension. Study Grou= ps may also terminate between plenary sessions if their proposed project is= approved by the IEEE Standards Association Standards Board.

Additionally, within the IEEE 8= 02 family of standards, there is a requirement that each new project propos= al attaches additional documentation that describes its engineering feasibi= lity, market potential, assurance of coexistence and distinct identity rela= tive to previous standards (referred to as the “CSD” in 802, wh= ich also includes the “5 criteria”). The “Criteria for St= andards Development (CSD)” used by IEEE 802 can be found in document:=

 https://mentor.ieee.org/802-ec/dcn/14/ec-14-0028-00-00EC-csd= -informative-extract.pdf

Also please note that IEEE meetings are open and may be attend= ed by any individuals who register and fulfill any registration fees. Detai= ls regarding future IEEE 802 plenary meeting schedules may be found at http://802world.= org/plenary/future-plenary-sessions/.   Please refer to individ= ual working groups for their interim meeting schedules. A listing of all wo= rking groups may be found at http://www.i= eee802.org/. 

Sincerely,

 

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC

jdambrosia@ieee.org=

 

 

= --_000_28616F4740DDF542AA1DB7C9F597963907AD48AF57AUSX7MCPS301A_-- --===============7643709485623123333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============7643709485623123333==-- From nobody Thu Apr 24 01:17:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1361A03A9 for ; Thu, 24 Apr 2014 01:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272, 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 uuaVboy1D-od for ; Thu, 24 Apr 2014 01:17:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 239391A04AA for ; Thu, 24 Apr 2014 01:17:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.7) with ESMTP id s3O8HBXr026100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Apr 2014 11:17:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.14.7/Submit) id s3O8HBU5015704; Thu, 24 Apr 2014 11:17:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21336.51335.189902.521625@fireball.kivinen.iki.fi> Date: Thu, 24 Apr 2014 11:17:11 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YooFe_8iqS4y4RJZE2u918ayjCA Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:17:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2014-04-24 Reviewer LC end Draft Dan Harkins T 2014-04-08 draft-ietf-idr-aigp-17 For telechat 2014-05-15 Phillip Hallam-Baker T 2014-04-01 draft-ietf-trill-esadi-07 Jeffrey Hutzelman T 2014-04-09 draft-ietf-mpls-psc-updates-05 For telechat 2014-05-29 Magnus Nystrom T 2014-05-16 draft-pal-eidr-urn-01 Last calls and special requests: Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Leif Johansson 2014-04-15 draft-ietf-ccamp-rsvp-te-eth-oam-ext-11 Tero Kivinen 2014-04-28 draft-ietf-bfd-mib-17 Warren Kumari 2014-04-28 draft-ietf-bfd-tc-mib-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Julien Laganier 2014-04-29 draft-ietf-dhc-dhcpv4-over-dhcpv6-07 Ben Laurie 2014-04-25 draft-ietf-rtcweb-use-cases-and-requirements-14 Matt Lepinski 2014-04-25 draft-ietf-salud-alert-info-urns-12 Catherine Meadows 2014-05-21 draft-eastlake-iana-cfm-considerations-01 Alexey Melnikov 2014-05-07 draft-ietf-appsawg-uri-get-off-my-lawn-04 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-09 Russ Mundy 2014-05-06 draft-ietf-mpls-extended-admin-group-05 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Sandy Murphy 2014-05-02 draft-ietf-ipsecme-esp-ah-reqts-07 Yoav Nir 2014-05-06 draft-ietf-opsawg-large-flow-load-balancing-11 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Brian Weis R2014-04-30 draft-ietf-radext-dtls-10 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Apr 24 08:22:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED141A03BA for ; Thu, 24 Apr 2014 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 GCfn7kZPqL1X for ; Thu, 24 Apr 2014 08:22:33 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 687301A037A for ; Thu, 24 Apr 2014 08:22:33 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so2554202iec.29 for ; Thu, 24 Apr 2014 08:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vParEr0ircA0QdhZ5FaFF4L3ZzTo4IpPT+4hrqMyPeo=; b=JXnzjZe0hJZr4K+7phihiTo/2CZkAa1xtlJlaQsQneZCcRhNWinMXFanapGy5liEeZ GL4nHbX+JMRyjEe6P39V+Llgm2zrZAEIWliwiQ3a+9+tns/14JhYRKBzGTmAI2y5JOTf WAsCtgGn2CzeEXKLjs5S8HIcw33CXREGYH6H8yiGRy1zwIa1PdDB73cjDzzEpe4FevtA 9A/3okIGg8LxfKTk7KJsThBX6uDjG5TO2lredtqfVQ9bDpE9Vr0qTcWXV+JREjCUv4kK SYkhHXeVqs6DLQ84+Pwarw+p7dm/C3MgjXFC/rNTaNqpDUtMNrTzQLyahI4Gf39aO30R a7Ng== MIME-Version: 1.0 X-Received: by 10.50.109.130 with SMTP id hs2mr4430759igb.29.1398352947186; Thu, 24 Apr 2014 08:22:27 -0700 (PDT) Received: by 10.42.95.208 with HTTP; Thu, 24 Apr 2014 08:22:27 -0700 (PDT) In-Reply-To: <534ff35a.63f2440a.2a54.101f@mx.google.com> References: <534D9EF6.4060106@bbn.com> <534ea310.ea42420a.3358.1b44@mx.google.com> <534FDD4E.10708@bbn.com> <534ff35a.63f2440a.2a54.101f@mx.google.com> Date: Thu, 24 Apr 2014 23:22:27 +0800 Message-ID: From: Lizhong Jin To: Stephen Kent , secdir , "zhliu@gsta.com" , "chen.ran@zte.com.cn" , "dcai@cisco.com" , "ssalam@cisco.com" , Adrian Farrel , "giheron@cisco.com" , "nabil.n.bitar@verizon.com" Content-Type: multipart/alternative; boundary=089e0111bc9ab012c404f7cb6a7e Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/91GmfX-IY4TTS26M4qv0JW3sJb4 Subject: Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:22:38 -0000 --089e0111bc9ab012c404f7cb6a7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, We upload the new version. The URL: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-06 Please check if you are OK with this version. Thank you for detail review. Regards Lizhong On Thursday, April 17, 2014, Lizhong Jin wrote: > Hi Stephen, > > See my reply inline below. Thank you. > > > > Regards > > Lizhong > > > > > > *From:* Stephen Kent [mailto:kent@bbn.com] > > *Sent:* Thursday, April 17, 2014 9:55 PM > *To:* Lizhong Jin; 'secdir'; zhliu@gsta.com; > chen.ran@zte.com.cn = ; > dcai@cisco.com ; > ssalam@cisco.com ; > 'Adrian Farrel'; giheron@cisco.com; > nabil.n.bitar@verizon.com > *Subject:* Re: SECDIR review of > draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 > > > > Lizhong, > > > Thanks for the quick reply. > > Hi Stephen, > > Thank you for the detail review. See my reply inline below. > > > > Regards > > Lizhong > > > > *From:* Stephen Kent [mailto:kent@bbn.com] > *Sent:* Wednesday, April 16, 2014 5:05 AM > *To:* secdir; zhliu@gsta.com; lizho.jin@gmail.com; chen.ran@zte.com.cn; > dcai@cisco.com; ssalam@cisco.com; Adrian Farrel; giheron@cisco.com; > nabil.n.bitar@verizon.com > *Subject:* SECDIR review of > draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 > > > > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > > > This is a very brief document, just 12 pages. The Abstract for this > document, n its entirety, says: =E2=80=9CIn many existing Virtual Private= LAN > Service (VPLS) deployments based on RFC 4762, inter-domain connectivity h= as > been deployed without node redundancy, or with node redundancy in a singl= e > domain. This document describes a solution for inter-domain VPLS based on > RFC 4762 with node and link redundancy in both domains.=E2=80=9D > > > > Unfortunately, this confusing wording is typical of the writing in severa= l > areas of this document. The RFC Editor will need to work closely with the > authors to make this document easier to read. Also, there are several > instances of acronyms used without expansion (e.g., ASBR), making reading > even harder. > > [Lizhong] I try to rephrase the abstract below to make it more clear. I > will check again for the acronyms in detail. BTW, the ASBR has been > expanded in section 3 line 193. > > The first use of ASBR is before then, I believe. > > [Lizhong] I see the first use of ASBR now. Will fix it. > > > > In many existing RFC 4762 based Virtual Private LAN Service (VPLS) > inter-domain deployments, the pseudowire (PW) connectivity has been > deployed without node redundancy, or with node redundancy only in a singl= e > domain. That will take high risk of service interruption, since at least > one domain will not have PW node redundancy. This document describes a > inter-domain VPLS solution which could provide PW node redundancy in both > domains. > > I think it would be clearer to say: > > In many existing Virtual Private LAN Service (VPLS) inter-domain > deployments (based on RFC 4762), pseudowire (PW) connectivity offers no > node redundancy, or offers node redundancy only with a single domain. Thi= s > deployment approach incurs a high risk of service interruption, since at > least one domain will not offer PW node redundancy. This document describ= es > an inter-domain VPLS solution that provides PW node redundancy across > domains. > [Lizhong] accepted, thank you. > > > > > > I like the fact that the document includes a =E2=80=9CMotivation=E2=80=9D= section. It > provided a good description of why a new approach to achieving redundancy > in the VPLS context is needed. > > > > Section 5 ends with a curious statement: > > > > There are two PW redundancy modes defined in [RFC6870]: > > Independent mode and Master/Slave mode. For the inter- > > domain four-PW scenario, it is required for PEs to ensure > > that the same mode is supported on the two ICCP peers in > > the same RG. One method to ensure mode consistency is by > > manual operation. Other methods are also possible and are > > out of the scope of this document. > > > > This says that two ASes have to ensure that both employ the same > redundancy mode choice, notes that they can verify this manually, and tha= t > says there are other options to meet this requirement, but provides no > description of the other options. Not very useful. > > [Lizhong] I think the text is OK. If you insist, I could remove. > > the text is not OK, because its states that there are multiple ways to > ensure consistency, but identifies only one. > [Lizhong] hope you are OK with Adrian=E2=80=99s proposal. > > > > ... > > Section 5.3 describes switchover operation in the more complex four PW > cases. It contains some RFC 2119 key words, but there are several instanc= es > of lowercase =E2=80=9Cshould=E2=80=9D. Is this intentional? > > [Lizhong] I will check again, some is intentional, but some is not. > > If you are defining rules for how to achieve switchover, use of > non-normative text is not > of much value. > > The Security Considerations section is brief, only 4 short paragraphs. > It cites the Security Considerations sections of RFCs 4762 and 6870, plus > the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the soluti= on > described here. > > > > RFC 4762 also contains a brief Security Considerations section, referring > the reader to RFC 4111, the PPVPN Security Framework. That document > discusses security in detail, although most of the discussion does not > appear to be directly applicable to the redundancy mechanisms of this > document. > > > > RFC 6870 is directly relevant. It contains a two-sentence Security > Considerations section (almost a record for brevity?) with a lowercase > =E2=80=9Cmust=E2=80=9D for emphasis? This section refers to RFC 4447, whi= ch contains a > meaningful SC section (finally). That document mandates use of the TCP/MD= 5 > option for LDP. This is almost consistent with the second paragraph of th= e > SC section in this document (which weakens this to a MAY), but not with t= he > third paragraph (which seems to call for TCP-AO). > > [Lizhong] RFC6870 SC is only valid for PW control plane. The second, > third and fourth paragraph is described for ICCP control plane. I will ma= ke > that clear in the text. > > OK. > > ... > > > > [Lizhong] thank you for the comments. I tend to remove the conflict parts > with [I-D.ietf-pwe3-iccp], and only describe the new security > considerations. Please help to review the following text: > > Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control > plane, [RFC4762] and [RFC6870] for PW control plane, this document will > have additional security consideration for ICCP control plane. > > > > In this document, ICCP protocol is deployed between two PEs or ASBRs. The > two PEs or ASBRs should only be connected by a well managed and highly > monitored network. This should be ensured by the operator. > > > > --089e0111bc9ab012c404f7cb6a7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen,
We upload the new version. The URL:=C2=A0http:= //tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-06<= /div>
Please check if you are OK with this version. Thank you for detail rev= iew.

Regards
Lizhong


On Thursday, April 17, 2014, Lizhong Jin <lizho.jin@gmail.com> wrote:

Hi Stephen,

See my reply inline below. Thank y= ou.

=C2=A0

Regards

Lizhong

=C2=A0

=C2=A0

From:= Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, April 17, 2014 9:55 PM
To: Lizhong Jin; 'secdir'; zhliu@gsta.com<= /a>; chen.ran@zte.com.cn; dcai= @cisco.com; ssalam@cisco.com; 'Adrian Farrel'; giheron@cisco.com; nabil.n.b= itar@verizon.com
Subject: Re: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

=C2=A0

Lizhong,


Thanks for the quick reply.

Hi Stephen,

Thank you for the detail revie= w. See my reply inline below.

=C2=A0

Regards

Lizhong

=C2=A0

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, April 16, 2014 5:05 AM
To: secdir; zhliu@gsta.com; lizho.jin@gmail.com; ch= en.ran@zte.com.cn; dcai@cisco.com; ssalam@cisco.com; Adri= an Farrel; giheron@cisco.com; nabil.n.bitar@verizon.com
Subject: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

=C2=A0

I reviewed this docum= ent as part of the security directorate's ongoing effort to review all IETF documents bein= g processed by the IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chair= s should treat these comments just like any other last call comments.<= span lang=3D"EN-US">

=C2=A0

This is a very brief document, just 12 pages. The Abstract for this document, n its entirety, says: =E2=80=9CIn ma= ny existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-dom= ain connectivity has been deployed without node redundancy, or with node redund= ancy in a single domain. This document describes a solution for inter-domain VPL= S based on RFC 4762 with node and link redundancy in both domains.=E2=80=9D <= u>

=C2=A0

Unfortunately, this confusing wording is typical of the writing in several areas of this document. The RFC Editor wi= ll need to work closely with the authors to make this document easier to read. Also, there are several instances of acronyms used without expansion (e.g., ASBR), making reading even harder.

[Lizhong] I try to rephrase th= e abstract below to make it more clear. I will check again for the acronyms in detail. BTW, the ASBR has been expanded in section 3 line 193.

The first use of ASBR is before then, I believe.

[Lizhong] I see= the first use of ASBR now. Will fix it.



In many existing RFC 4762 base= d Virtual Private LAN Service (VPLS) inter-domain deployments, the pseudowire (PW) connectivity has been deployed without node redundancy, or with node redund= ancy only in a single domain. That will take high risk of service interruption, since at least one domain will not have PW node redundancy.=C2=A0 This docu= ment describes a inter-domain VPLS solution which could provide PW node redundan= cy in both domains.

I think it would be clearer to = say:

In many existing Virtual Private LAN Service (VPLS) i= nter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no node redundancy= , or offers node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will = not offer PW node redundancy. This document describes an inter-domain VPLS solu= tion that provides PW node redundancy across domains.
[Lizhong] accepted, tha= nk you.

=C2=A0

=C2=A0

I like the fact that the document includes a =E2=80=9CMotivation=E2=80=9D section. It provided a good descrip= tion of why a new approach to achieving redundancy in the VPLS context is needed.

=C2=A0

S= ection 5 ends with a curious statement:<= u>

= =C2=A0

There are two PW redundancy modes defined in [RFC6870]:

Independent mode and Master/Slave mode.=C2=A0 For the inter-

domain four-PW scenario, it is required for PEs to ensure

that the same mode is supported on the two ICCP peers in

the same RG.=C2=A0 One method to ensure mode consistency is by

manual operation.=C2=A0 Other methods are also possible and are

out of the scope of this document.

= =C2=A0

T= his says that two ASes have to ensure that both employ the same redundancy mode choice, notes that they can verif= y this manually, and that says there are other options to meet this requireme= nt, but provides no description of the other options.=C2=A0 Not very useful.

= =C2=A0[Lizhong] I think the text is OK. If you insist, I could remove.

the text is not OK, because its= states that there are multiple ways to ensure consistency, but=C2=A0 identifies only on= e.
[Lizhong] hope you are = OK with Adrian=E2=80=99s proposal.=

=C2=A0

...

Section 5.3 describes= switchover operation in the more complex four PW cases. It contains some RFC 2119 key words, but there are several instances of lowercase =E2=80=9Cshould=E2=80= =9D. Is this intentional?

=C2=A0[Lizhong] I will c= heck again, some is intentional, but some is not.

If you are defining rules for how to achieve switchover, use of non-normative text is not
of much value.

The Security Consider= ations section is brief, only 4 short paragraphs.=C2=A0 It cites the Security Considerations sections of RFCs 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that fo= rms the basis of part of the solution described here.

=C2=A0

RFC 4762 also contain= s a brief Security Considerations section, referring the reader to RFC 4111, the PPVPN Securit= y Framework. That document discusses security in detail, although most of the discussion does not appear to be directly applicable to the redundancy mechanisms of this document.

=C2=A0

RFC 6870 is directly = relevant. It contains a two-sentence Security Considerations section (almost a record for brevity= ?) with a lowercase =E2=80=9Cmust=E2=80=9D for emphasis? This section refers t= o RFC 4447, which contains a meaningful SC section (finally). That document mandates use of t= he TCP/MD5 option for LDP. This is almost consistent with the second paragraph= of the SC section in this document (which weakens this to a MAY), but not with= the third paragraph (which seems to call for TCP-AO).

=C2=A0[Lizhong] RFC6870 = SC is only valid for PW control plane. The second, third and fourth paragraph is described f= or ICCP control plane. I will make that clear in the text.

OK.

...

=C2=A0

[Lizhong] thank you for the co= mments. I tend to remove the conflict parts with [I-D.ietf-pwe3-iccp], and only describe the new securit= y considerations. Please help to review the following text:

Besides the security propertie= s of [I-D.ietf-pwe3-iccp] for ICCP control plane, [RFC4762] and [RFC6870] for PW control plane, this document = will have additional security consideration for ICCP control plane.

= =C2=A0

In this document, ICCP protoco= l is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed and highly monitored network. This should be ensured by the operator.

=C2=A0

--089e0111bc9ab012c404f7cb6a7e-- From nobody Thu Apr 24 08:52:27 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FDB1A00E1 for ; Thu, 24 Apr 2014 08:52:25 -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 rB3JlMZXLVR3 for ; Thu, 24 Apr 2014 08:52:23 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE01A02CC for ; Thu, 24 Apr 2014 08:52:22 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pv20so2137165lab.24 for ; Thu, 24 Apr 2014 08:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cyr7wxacSNJS8UlS9MN4eKNX/XhKbP0ADyv79d2rq/8=; b=mE/+FkG0c/CSjICySZ/xngUXgdDhR1z8hsv4IyVrzBLzrdvvUoyYiPEG1x8XdMxt+Y g5E5g+4PxbA96gzVL2DGEsIppTXbM5aoHMGyxQ7dVlqY//66lcRb8bfkPvzCmgGOLA8U x7AdQgG5Zm/wA596q4dvjAJI+actInWGmXZog7Oeu+F4aycS9JODnQsgyFX6ls2td9fj 7HINbeT6aJiQnVGzZo94qVT78Wex1+/1NLjX2jPsl0svOegt9p0/bFtnVO9JdLXEucWf +b40QYi65RcF7DqJwjsdE7iTOv8/Gg90AUJoJ9nz/aueRI600UREdMxEvyDzvqIpIL5Q M0IQ== MIME-Version: 1.0 X-Received: by 10.112.241.73 with SMTP id wg9mr1680703lbc.48.1398354736527; Thu, 24 Apr 2014 08:52:16 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 24 Apr 2014 08:52:15 -0700 (PDT) Date: Thu, 24 Apr 2014 11:52:15 -0400 Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" , draft-ietf-trill-esadi.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KWwtNS61COz6jCbrzPL3A0WIDfU Subject: [secdir] SECDIR review of draft-ietf-trill-esadi-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:52:25 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is describing extensions to a routing infrastructure. As such the only security properties that are reasonably achievable without inappropriate assumptions such as trustworthy routing nodes is to assure continuity of service. We should assume that authentication and confidentiality of the message content are assured via some end-to-end means where the ends are the source and destination of the messages. [It would be rather useful if the IAB would draft a document that would state what security properties are expected at which level] ESADI does provide for improved service assurances by allowing the authentication of nodes. What is less clear is how this authentication is leveraged Section 5.1 suggests that authenticating endpoints permits higher confidence to be built up. if end nodes are authenticated to their MAC address. But this authentication only has value if there is a chain of custody authentication to the relying party. Section 6.2 describes a mechanism that might be relevant here. A pointer would be helpful. -- Website: http://hallambaker.com/ From nobody Thu Apr 24 12:30:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4625C1A038E; Thu, 24 Apr 2014 12:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] 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 PyEsRe644xtk; Thu, 24 Apr 2014 12:30:14 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) by ietfa.amsl.com (Postfix) with ESMTP id 58E841A036B; Thu, 24 Apr 2014 12:30:14 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s3OJU60i010700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Apr 2014 15:30:06 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_05A96DF5-9F1D-4906-B11A-4BF562D79065" Date: Thu, 24 Apr 2014 15:30:06 -0400 Message-Id: <1CAC54C2-F23B-43A4-ABB5-B936D2ECC827@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-eastlake-iana-cfm-considerations.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/me74uaPAAEy0mG37M-gr0kEMcHs Subject: [secdir] Secdir review of draft-eastlake-iana-cfm-considerations-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:30:16 -0000 --Apple-Mail=_05A96DF5-9F1D-4906-B11A-4BF562D79065 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This short document specifies the IANA considerations for the blocks of = CFM Op-codes and TLV types allocated to the IETF in the CFM OAV facilities specified by = IEEE 802.1 This document requests that IANA create a CFM OAM IETF Op-Codes registry = and a CFM OAM IETF TLV Types Registry, stating which blocks of values are = involved and noting from where the parameters originate (IEEE 802.1). In the Security Considerations the authors note that the document is not = directly concerned with security, and there are no security considerations. I agree with them; all the document does is request the creation of two = new registries and note the parameters.=20 I have no further comments to make from a security point of view. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_05A96DF5-9F1D-4906-B11A-4BF562D79065 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I have = reviewed this document as part of the security directorate's
ongoing = effort to review all IETF documents being processed by the
IESG. =  These comments were written primarily for the benefit of = the
security area directors.  Document editors and WG chairs = should treat
these comments just like any other last call = comments.

This short document specifies the IANA = considerations for the blocks of CFM Op-codes and
TLV types = allocated to the IETF in the CFM OAV facilities specified by IEEE = 802.1
This document requests that IANA create a CFM OAM IETF = Op-Codes registry and
a CFM OAM IETF TLV Types Registry, = stating which blocks of values are involved and noting = from
where the parameters originate (IEEE = 802.1).

In the Security Considerations the = authors note that the document is not directly concerned with security, = and there
are no security considerations.
I agree = with them; all the document does is request the creation of two new = registries and note the parameters. 

I = have no further comments to make from a security point of = view.


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail=_05A96DF5-9F1D-4906-B11A-4BF562D79065-- From nobody Fri Apr 25 09:59:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0331A0658; Fri, 25 Apr 2014 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 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, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, 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 Yg80kfbCTXEb; Fri, 25 Apr 2014 09:59:28 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7753C1A063E; Fri, 25 Apr 2014 09:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1385; q=dns/txt; s=iport; t=1398445162; x=1399654762; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=IbFUam7/3J4/twefl9cOvvhA8LVXCYgfWJWCLdip/yg=; b=SNYdIsRUYzCDZTdINMZ7Pk4ggvsyLFo8WQFEy0614E/5T20r9SZ1hV5o OuDpiatleTaYVx6uI/J3WqBgPsIupZPb9lp36rpK6nXEQ7msDjKXEiYfU mt/x+7K8+GUjQpXxtMKnUf6ZOHcs6Z901Gb//wwnlseGEDJaqxTFzfxVU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoIADOTWlOrRDoI/2dsb2JhbABZgwarUZl0gRMWdIJmP4E+AYhSykIXhVqIf4MrgRUEiW2PGJJcg1Ed X-IronPort-AV: E=Sophos;i="4.97,928,1389744000"; d="scan'208";a="111108386" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 25 Apr 2014 16:59:20 +0000 Received: from stealth-10-32-244-211.cisco.com (stealth-10-32-244-211.cisco.com [10.32.244.211]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3PGxJJN025066; Fri, 25 Apr 2014 16:59:20 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Apr 2014 09:59:19 -0700 Message-Id: To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/T8ltb_8qGJH9JLJBwC-MX662dkg Cc: draft-ietf-radext-dtls.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-radext-dtls-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:59:31 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This is a re-review; I last reviewed draft-ietf-radext-dtls-06. = Reproducing my summary from that review: This document describes = requirements and implementation details regarding using DTLS as a = transport layer for RADIUS packets. It is a companion to RFC 6614 ("TLS = Encryption for RADIUS"), and this I-D references many of the sections in = that RFC rather than re-defining them. While the security considerations = of encapsulating RADIUS in TLS and DTLS are very similar there are a = number of operational issues where a UDP protocol is more advantageous = than a TCP, and vice versa. Both documents are worth specifying; = providing more secure alternatives to the simple RADIUS MD5 integrity = checks is critical. The current draft addresses my earlier comments, and is much improved = due to other changes as well. I believe is ready to publish. I noticed one nit in the "DTLS Data" definition (Section 5.1): = s/variable which may information about/variable which may contain = information about/. Brian= From nobody Fri Apr 25 11:05:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0F41A05C3; Fri, 25 Apr 2014 11:05:23 -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 myixJ4eSlRNx; Fri, 25 Apr 2014 11:05:21 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B138D1A065B; Fri, 25 Apr 2014 11:05:20 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id u14so365803lbd.2 for ; Fri, 25 Apr 2014 11:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZkuZtO2AJSgPhEhGiAIhf6vq80UnlX7eR/MQEfz1CKE=; b=o51qApMAlAlRqOh8zmvAqTQ5LXL3Chdcvk82CcaW3aH5Mo1r7EYLaR6Gb73jVBYqWW +UAD8lzvSakQQRoDajxFlauk7z40ahz00Vrcxk1JH7J//oXyBx+feCiD/nnW2R9Vf7Rw Fob2whj5qm+/Mlkdp1z1dMQl6lonBqfa6pe2G/sDGoFrd7GLKLLRmLu4U/kxhqfrO/5B 6Z5IhlFcBx4uhauwL4lkPKsW414IQq1iJL6Fte77mbtn1526v0szi+czKx8zlM083dGk HlruJ4qT7DMqZoGjPaj7b+8DLwKjwj894R1kYPYrHzb1kJg4IzFL3q8uqsyv5zR6PX8H 8jCQ== X-Received: by 10.152.4.41 with SMTP id h9mr2217667lah.43.1398449113478; Fri, 25 Apr 2014 11:05:13 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPSA id q4sm8859694lbh.20.2014.04.25.11.05.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Apr 2014 11:05:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Fri, 25 Apr 2014 21:05:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <008F4E44-C5D6-4E4F-B799-F179126F9745@gmail.com> References: To: Brian Weis X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ziEz8yzOyfuzlDrjSb0lqgiJElg Cc: draft-ietf-radext-dtls.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:05:23 -0000 Thanks Brian. We'll take care of the nit your spotted. - Jouni On Apr 25, 2014, at 7:59 PM, Brian Weis wrote: > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This is a re-review; I last reviewed draft-ietf-radext-dtls-06. = Reproducing my summary from that review: This document describes = requirements and implementation details regarding using DTLS as a = transport layer for RADIUS packets. It is a companion to RFC 6614 ("TLS = Encryption for RADIUS"), and this I-D references many of the sections in = that RFC rather than re-defining them. While the security considerations = of encapsulating RADIUS in TLS and DTLS are very similar there are a = number of operational issues where a UDP protocol is more advantageous = than a TCP, and vice versa. Both documents are worth specifying; = providing more secure alternatives to the simple RADIUS MD5 integrity = checks is critical. >=20 > The current draft addresses my earlier comments, and is much improved = due to other changes as well. I believe is ready to publish. >=20 > I noticed one nit in the "DTLS Data" definition (Section 5.1): = s/variable which may information about/variable which may contain = information about/. >=20 > Brian From nobody Mon Apr 28 06:47:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659821A09F9; Mon, 28 Apr 2014 06:47:57 -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 I18Mori3r218; Mon, 28 Apr 2014 06:47:55 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 771411A0795; Mon, 28 Apr 2014 06:47:55 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id x12so880493wgg.11 for ; Mon, 28 Apr 2014 06:47:54 -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:message-id:date :to:mime-version; bh=dUxyjYw1Z/RZNGea6uoZKSVPTcSLV1lvpjbMhREijQM=; b=GnLrF3KA8+y3bjrf8ckAN3y4XDUazr6mxNZ4tUJPpkeAiiNUsyOujCQsnxY1mv9Uwr J/oi9tkdi0+APJtpU1YrveIrV156kSR+nvmJu3Ki4BrX/T3/Ux7mCnCYTWpnVG1HcQGk eO3VF9Ki76AyntQlylIO4V7qIz0VBgyUZUrCooywq7NQX02+sV1CJ95ut/G6COj8VrP2 qxIW1SvKTPMBnNtlrq4n6h0cx1Aw1coMQXu0Gy/vckk5REJJQS/VsGHBOAs3x72UME2f 0uhUouajL4nq3uRcK64TWwYOhvvi88Uk+PKWnL06HYDm53mJPQJhMdFWIPCzhv8e9i6c AO+Q== X-Received: by 10.180.228.42 with SMTP id sf10mr15688006wic.48.1398692874352; Mon, 28 Apr 2014 06:47:54 -0700 (PDT) Received: from [172.24.248.99] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id h3sm17880253wiz.16.2014.04.28.06.47.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 06:47:53 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <0D637AC0-FD4F-4865-8D14-ADB75BAB072E@gmail.com> Date: Mon, 28 Apr 2014 16:47:48 +0300 To: draft-ietf-opsawg-large-flow-load-balancing.all@tools.ietf.org, "" , " IESG" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MNAntvFB8zf9WqHP-Bk8k67IikQ Subject: [secdir] Secdir review of draft-ietf-opsawg-large-flow-load-balancing-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 13:47:57 -0000 Hi I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. tl;dr version: the document is ready. I was a little surprised by the way the document is organized, and I=92m = not sure who the target audience is. On the one hand it is very verbose = on explanations (that=92s a good thing!) and I could very well = understand it even though I lack any background on the matter. On the = other hand, the order in which things are explained seems strange: The introduction talks about large flows vs small flows, long-lived = flows vs short-lived flows, and Large flows vs Small flows (no, I=92m = not repeating myself, capitalize Large is different from lower-case = large and in fact means both =93large=94 and =93long-lived=94). But = three things are totally missing: What is a flow? How large does a flow = have to be to be considered =93large=94 (lower case), and how long must = a flow continue to be considered =93long-lived=94. Even the terminology = section (1.2) defines Large, Small and small again, but not what a flow = is. These concepts are finally explained in sections 4.1, 4.3.1, and = 4.3.2. The document describes how load balancing can be achieved by moving = large flows around between links and by removing loaded links from the = hash table, so that Small (or actually un-classified) new flows will not = go to overloaded links. This is an improvement over the assumed default = that is statically assigning flows to links based on a hash. The document has a short security considerations section that says that = it does not impact the security of the Internet infrastructure or = applications. I tend to agree, because the parts of the network where = these protocols tends to be mostly stateless, so moving flows from one = component to another should not make a difference. It would be different = if there were supposed to be firewalls on the nodes. The security considerations also says that load balancing might help in = resisting DoS attacks, for example if an attacker can create traffic = where the hash would collide with some Large flow. With load balancing = either the attacker=92s flow or the Large flow is moved, eliminating the = contention. Again, I tend to agree, although this will allow a more = powerful attacker to overload all the links, not just the ones they can = target with the hash function. Still, an attacker powerful enough to = overload all the links is likely to be able to create traffic that = collides with all links anyway. I don=92t think there=92s anything missing from the security = considerations. Hope this helps Yoav From nobody Wed Apr 30 08:47:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159EE1A08E8; Wed, 30 Apr 2014 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1yrGZZyZj02h; Wed, 30 Apr 2014 08:47:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC6B1A08E2; Wed, 30 Apr 2014 08:47:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2DF622240093; Wed, 30 Apr 2014 17:46:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu34Yq8rxpyg; Wed, 30 Apr 2014 17:46:55 +0200 (CEST) Received: from Thor.local (unknown [67.71.146.163]) by power.freeradius.org (Postfix) with ESMTPSA id 6F5DC2240048; Wed, 30 Apr 2014 17:46:55 +0200 (CEST) Message-ID: <53611AEE.7060906@deployingradius.com> Date: Wed, 30 Apr 2014 11:46:54 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Brian Weis References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eeKfdT1qJCd10y2m5tR3lov23kU Cc: draft-ietf-radext-dtls.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-radext-dtls-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 15:47:35 -0000 Brian Weis wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This is a re-review; I last reviewed draft-ietf-radext-dtls-06. Reproducing my summary from that review: This document describes requirements and implementation details regarding using DTLS as a transport layer for RADIUS packets. It is a companion to RFC 6614 ("TLS Encryption for RADIUS"), and this I-D references many of the sections in that RFC rather than re-defining them. While the security considerations of encapsulating RADIUS in TLS and DTLS are very similar there are a number of operational issues where a UDP protocol is more advantageous than a TCP, and vice versa. Both documents are worth specifying; providing more secure alternatives to the simple RADIUS MD5 integrity checks is critical. > > The current draft addresses my earlier comments, and is much improved due to other changes as well. I believe is ready to publish. > > I noticed one nit in the "DTLS Data" definition (Section 5.1): s/variable which may information about/variable which may contain information about/. Fixed, thanks. From nobody Wed Apr 30 09:08:43 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941EA1A0928 for ; Wed, 30 Apr 2014 09:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 5tBjDEAxyo6P for ; Wed, 30 Apr 2014 09:08:40 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2816C1A08E8 for ; Wed, 30 Apr 2014 09:08:40 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id eb12so2210553oac.18 for ; Wed, 30 Apr 2014 09:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ry/fNMi0uDG40vjl2q0eLpsebHZcTzfehIGieHMkf1Y=; b=pYgNlDGaOb0fa0WlTuNM8/DoY+sK4tmXvDOhv6shkFmV18uNIMbaFHDeDS787fWCkA jq47XT9CEaf3NOMslYPHBChUfkCG9vW4e+PKjmqWJq/5eJRECqLL/N8i9r/0Wy8P4KAI 9PC8ulN+6XklHDxuWC17lQHWvYQmwrhZ5s1wdtNDxRAXG4t321V7POlk9LFeuzE6SrUR yTZjw4NA6MPRyVsn7Kw3fNwZY8sN6MTq2XgHFNfQ/vF1UkVucwNxKBPBBs4bGmFclvsQ TAdyixervsvjmxyvM7A+K8E8CG/WqYHb6fnyMu0W+tqEpAKERkhSHY8mJuY7096xEcbC xHUg== X-Received: by 10.182.22.227 with SMTP id h3mr4934312obf.36.1398874118485; Wed, 30 Apr 2014 09:08:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.25.41 with HTTP; Wed, 30 Apr 2014 09:08:18 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 30 Apr 2014 12:08:18 -0400 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/kFYG4Y_LDZy5LhmGQ2vYhF1Em9I Cc: draft-ietf-trill-esadi.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-trill-esadi-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 16:08:41 -0000 Hi Phil, On Thu, Apr 24, 2014 at 11:52 AM, Phillip Hallam-Baker wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > This document is describing extensions to a routing infrastructure. > As such the only security properties that are reasonably achievable > without inappropriate assumptions such as trustworthy routing nodes > is to assure continuity of service. We should assume that > authentication and confidentiality of the message content are > assured via some end-to-end means where the ends are the source and > destination of the messages. I agree that people should use end-to-end security to protect their data in transit but that isn't really related to this ESADI document. It is helpful to have read RFC 6325, the TRILL base protocol specification, in understanding this document, which is why the ESADI draft says "familiarity with [RFC6325] is particularly assumed". I view this ESADI document as providing two things: (1) A reliable information flooding mechanism that is scoped by data label (VLAN or fine grained label) such that, in a quiescent network, all TRILL switches that have advertised interest in a particular label will end up with the same flooded information state associated with that label. (2) A method of using the facility in item (1) above to flood information on the reachability of end stations by edge TRILL switches. Edge TRILL switches need to learn what end station destinations are reachable from (i.e., connected to) edge TRILL switch in order to efficiently handle end station traffic. By default they learn from observation of the data plane. ESADI provide a mechanism whereby such reachability information for an end station in data label X, however learned, can be flooded to all TRILL switches that also advertise interest in data label X and are participating in ESADI for data label X. ESADI uses essentially the same mechanisms to authenticate its reliable flooding mechanism as does IS-IS. End stations reachability information can be learned through cryptographically hardened Layer 2 registration methods a couple of which I give as examples below. This ESADI document does not specify any such Layer 2 end station registration methods and does not require their use but suggests that their use could improve security. > [It would be rather useful if the IAB would draft a document that > would state what security properties are expected at which level] > > ESADI does provide for improved service assurances by allowing the > authentication of nodes. End stations can authenticate to an edge TRILL switch if the edge TRILL switch supports an existing Layer 2 authentication/registration protocol. Example registration protocols might be Wi-Fi (IEEE 802.11) association and authentication or IEEE 802.1X port based authentication, both of which use the IETF EAP (Extensible Authentication Protocol). > What is less clear is how this authentication is leveraged Section > 5.1 suggests that authenticating endpoints permits higher confidence > to be built up. if end nodes are authenticated to their MAC > address. But this authentication only has value if there is a chain > of custody authentication to the relying party. Section 6.2 > describes a mechanism that might be relevant here. A pointer would > be helpful. TRILL has a facility for assigning a one byte unsigned integer confidence level to any particular association of a destination to an edge TRILL switch from which that destination is reachable. Section 5.1 mentions that it is reasonable for the network manager to assign a higher confidence level to such edge TRILL switch end station reachability information if it was learned through a secured registration protocol. I think you meant to refer to Section 6.3 that talks about authenticating ESADI PDUs, particularly the default authentication if nothing more specific is configured. That mechanism can be used to authenticate end station destination reachability information as it is flooded with ESADI and provides at least some sort of "chain of custody", as you refer to it, between the originating TRILL switch and the relying TRILL switch. You say "a pointer would be helpful" but I'm not sure what pointer you want. We could add a reference to RFC 5310, "IS-IS Generic Cryptographic Authentication" since, as I say, the method for authenticating ESADI PDUs is essentially the same as that used in IS-IS. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- > Website: http://hallambaker.com/