From nobody Fri Jan 2 06:33:13 2015 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 46BCB1A8752 for ; Fri, 2 Jan 2015 06:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 nEl6eZ6d-jIu for ; Fri, 2 Jan 2015 06:33:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006C11A875C for ; Fri, 2 Jan 2015 06:33:09 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t02EX6E2005517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 2 Jan 2015 16:33:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t02EX6dv005320; Fri, 2 Jan 2015 16:33:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21670.44066.161079.72829@fireball.kivinen.iki.fi> Date: Fri, 2 Jan 2015 16:33:06 +0200 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/2Ong8YRx6NvCNqXafMBABlMFcq4 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: Fri, 02 Jan 2015 14:33:12 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Adam Montville is next in the rotation. For telechat 2015-01-08 Reviewer LC end Draft Alan DeKok T 2015-01-01 draft-higgs-hbbtv-urn-00 Olafur Gudmundsson T 2014-12-24 draft-ietf-ospf-te-metric-extensions-09 Benjamin Kaduk T 2014-12-25 draft-ietf-sfc-problem-statement-10 David Waltermire T 2014-12-09 draft-ietf-kitten-cammac-00 For telechat 2015-01-22 Sam Hartman T 2015-01-09 draft-farrkingel-pce-abno-architecture-14 Chris Inacio T 2015-01-07 draft-ietf-pcp-server-selection-07 Charlie Kaufman TR2015-01-12 draft-ietf-mpls-in-udp-09 Tero Kivinen T 2015-01-14 draft-ietf-json-i-json-05 Matt Lepinski T 2015-01-14 draft-ietf-httpbis-header-compression-10 Chris Lonvick T 2015-01-14 draft-ietf-httpbis-http2-16 Last calls and special requests: Shawn Emery 2014-12-24 draft-ietf-aqm-recommendation-08 Dorothy Gellert 2014-12-22 draft-ietf-ippm-rate-problem-08 Tobias Gondrom 2014-12-18 draft-ietf-mpls-ldp-ipv6-14 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-12-22 draft-ietf-tsvwg-port-use-06 David Harrington 2014-12-24 draft-ietf-tsvwg-sctp-dtls-encaps-07 Paul Hoffman 2015-01-08 draft-holmberg-dispatch-iotl-03 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-07 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Leif Johansson 2014-12-25 draft-ietf-radext-radius-fragmentation-09 Stephen Kent E None draft-ietf-i2rs-problem-statement-04 Warren Kumari 2015-01-17 draft-ietf-ccamp-general-constraint-encode-16 Ben Laurie 2015-01-08 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14 Matt Lepinski 2014-11-18 draft-nottingham-safe-hint-05 Catherine Meadows 2015-01-26 draft-ietf-l2vpn-pbb-evpn-09 Alexey Melnikov 2015-01-14 draft-ietf-opsawg-coman-probstate-reqs-03 Matthew Miller 2015-01-14 draft-ietf-opsawg-coman-use-cases-03 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-08 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 -- kivinen@iki.fi From nobody Fri Jan 2 07:41:33 2015 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 08FF31A0378; Fri, 2 Jan 2015 02:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] 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 VbTSuHmk8jf7; Fri, 2 Jan 2015 02:19:29 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87621A0363; Fri, 2 Jan 2015 02:19:28 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.207]) by smtp-cloud6.xs4all.net with ESMTP id ayKS1p00C4U4Moq01yKStU; Fri, 02 Jan 2015 11:19:27 +0100 Received: from AMontpellier-654-1-146-105.w90-0.abo.wanadoo.fr ([90.0.217.105]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 02 Jan 2015 11:19:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 02 Jan 2015 11:19:26 +0100 From: peter van der Stok To: Steve.Hanna@infineon.com Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> Message-ID: <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> X-Sender: stokcons@xs4all.nl (vPLXpqckJ34U/IBAQIO594mPimJ2WR1B) User-Agent: XS4ALL Webmail Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0kVg4HGW3SUn1j5QbsRxWgaOTI8 X-Mailman-Approved-At: Fri, 02 Jan 2015 07:41:31 -0800 Cc: iesg@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 10:19:31 -0000 Dear Steve, thanks for the comments. I will respond below to the points you raise. Greetings, Peter Steve.Hanna@infineon.com schreef op 2014-12-30 13:55: > This document describes a technique for automatically managing the > boundaries of the admin-local multicast scope in a border router, > using MPL (Multicast Protocol for Low power and Lossy Networks). Correct > > In my view, this document is Not Ready. > > The document is hard to understand. For example, the acronyms MPL and > MPL4 are used throughout the document but they are not defined. You are the third to remark on this point. Adrian did suggestions to improve the document with a definition of MPL, that we will take over. MPL4 concepts are defined in section 1.2. > > After reading the document several times, I have concluded that > section 3.2 contains the most important part of the document: an > algorithm for automatically defining the boundaries of the admin-local > multicast scope using MPL. This section basically says that a border > router should periodically send an MPL message on all interfaces to > the ALL_MPL_FORWARDERS multicast address with admin-local scope. It > should also listen for such messages on all interfaces. If it receives > such a message, that interface should be marked as part of the > admin-local scope. > > This algorithm seems problematic from a security standpoint. Because > any device on a network can send an MPL message to the > ALL_MPL_FORWARDERS multicast address with admin-local scope, the > boundaries of the admin-local multicast scope can be expanded by > attackers fairly easily. Such manipulation may permit nodes that > should be outside a particular administrative domain to join that > domain and participate in receiving and sending multicast traffic > within that domain. The implications of such an attack are not clear > to me because I am not familiar with the protocols and devices that > use admin-local multicast scope. However, it seems likely that > expanding the admin-local multicast scope will permit external > attackers to more easily monitor multicast traffic that should be > private and to inject multicast messages into a relatively trusted > domain. In the discussion with Joel, we came to the conclusion that we were not very clear with respect to the administrative zone specification. We suggested to limit the mpl admin-local scope within one zone. The text will be extended to include this extra limit on the boundary of admin-local-scope. The extent of the scope does not specify anything about the contents of the MPL messages. It is expected that MPL messages are encrypted depending on the wanted security level. Monitoring by an attacker limits itself to counting messages, which is already possible on wireless links any way. To inject messages, the attacker should know the keys necessary to encrypt. When messages are not encrypted they are already readable on the wireless links, and the monitoring by extending the mpl-admin-local scope does not increase the vulnerability to snooping the messages. > > In addition to this fundamental concern, I have a few minor concerns > about the readability of the document. However, I seem to have mislaid > my notes during the holidays. Because this review is already late and > I'm on vacation, I will send the review now and follow up with the > minor concerns at a later date if I can find them when I return to the > office. If you find terms which are not defined in this draft, ietf-rol-trickle-mcast or RFC7346, I will be happy to extend the definitions of section 1.2. > > Thanks, > > Steve From nobody Fri Jan 2 10:27:25 2015 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 6691B1A01CB; Fri, 2 Jan 2015 10:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, 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 26qyjSh80zhw; Fri, 2 Jan 2015 10:26:56 -0800 (PST) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF7D1A1B6C; Fri, 2 Jan 2015 10:26:55 -0800 (PST) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jan 2015 19:26:54 +0100 Received: from MUCSE609.infineon.com (mucltm01.eu.infineon.com [172.23.8.248]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Fri, 2 Jan 2015 19:26:52 +0100 (CET) Received: from KLUSE612.infineon.com (172.28.156.138) by MUCSE609.infineon.com (172.23.7.110) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 2 Jan 2015 19:26:52 +0100 Received: from KLUSE610.infineon.com (172.28.156.137) by KLUSE612.infineon.com (172.28.156.138) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 2 Jan 2015 19:26:51 +0100 Received: from KLUSE610.infineon.com ([172.28.148.8]) by KLUSE610.infineon.com ([172.28.148.8]) with mapi id 15.00.0995.032; Fri, 2 Jan 2015 19:26:51 +0100 From: To: Thread-Topic: secdir review of draft-ietf-roll-admin-local-policy-02 Thread-Index: AdAff2eol7wcDrkvTNS1G9OE6YCkGQG7cxgAAA8u32A= Date: Fri, 2 Jan 2015 18:26:50 +0000 Message-ID: <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> In-Reply-To: <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A15_01D0268F.C1F40D00" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EdVerhLI5pH3BTvBthL6XZfA4Ec Cc: iesg@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-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, 02 Jan 2015 18:27:00 -0000 ------=_NextPart_000_0A15_01D0268F.C1F40D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Peter, Thanks for your prompt response. I have added some more comments below, delimited with . Steve -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: Friday, January 02, 2015 5:19 AM To: Hanna Steve (IFNA CCS SMD AMR) Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-roll-admin-local-policy.all@tools.ietf.org Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02 Dear Steve, thanks for the comments. I will respond below to the points you raise. Greetings, Peter Steve.Hanna@infineon.com schreef op 2014-12-30 13:55: > This document describes a technique for automatically managing the > boundaries of the admin-local multicast scope in a border router, > using MPL (Multicast Protocol for Low power and Lossy Networks). Correct > > In my view, this document is Not Ready. > > The document is hard to understand. For example, the acronyms MPL and > MPL4 are used throughout the document but they are not defined. You are the third to remark on this point. Adrian did suggestions to improve the document with a definition of MPL, that we will take over. MPL4 concepts are defined in section 1.2. I'm happy to see that you'll be adding a definition of MPL. That's good. While it's true that section 1.2 defines several terms that include MPL4 (e.g., "MPL4 message"), the term "MPL4" is never defined anywhere. I found that confusing. > > After reading the document several times, I have concluded that > section 3.2 contains the most important part of the document: an > algorithm for automatically defining the boundaries of the admin-local > multicast scope using MPL. This section basically says that a border > router should periodically send an MPL message on all interfaces to > the ALL_MPL_FORWARDERS multicast address with admin-local scope. It > should also listen for such messages on all interfaces. If it receives > such a message, that interface should be marked as part of the > admin-local scope. > > This algorithm seems problematic from a security standpoint. Because > any device on a network can send an MPL message to the > ALL_MPL_FORWARDERS multicast address with admin-local scope, the > boundaries of the admin-local multicast scope can be expanded by > attackers fairly easily. Such manipulation may permit nodes that > should be outside a particular administrative domain to join that > domain and participate in receiving and sending multicast traffic > within that domain. The implications of such an attack are not clear > to me because I am not familiar with the protocols and devices that > use admin-local multicast scope. However, it seems likely that > expanding the admin-local multicast scope will permit external > attackers to more easily monitor multicast traffic that should be > private and to inject multicast messages into a relatively trusted > domain. In the discussion with Joel, we came to the conclusion that we were not very clear with respect to the administrative zone specification. We suggested to limit the mpl admin-local scope within one zone. The text will be extended to include this extra limit on the boundary of admin-local-scope. The extent of the scope does not specify anything about the contents of the MPL messages. It is expected that MPL messages are encrypted depending on the wanted security level. Monitoring by an attacker limits itself to counting messages, which is already possible on wireless links any way. To inject messages, the attacker should know the keys necessary to encrypt. When messages are not encrypted they are already readable on the wireless links, and the monitoring by extending the mpl-admin-local scope does not increase the vulnerability to snooping the messages. Please send me a copy of your new text limiting the admin-local scope to one zone. I don't see how this will help but maybe the new text will make it clear. You just stated that "It is expected that MPL messages are encrypted". However, this is never stated in draft-ietf-roll-trickle-mcast-11.txt or in draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no mention of encryption in those documents at all. If the security of your design depends on this encryption, you'd better talk about it somewhere! Now I'd like to investigate the security provided by this encryption. Are you expecting that application-layer encryption will be used? I suppose not because that would require extensive description And you provided none. Probably you're thinking about link-layer encryption such as that provided by IEEE 802.11i. However, I don't think that such encryption will prevent the attacks that I described. A border router frequently spans networks that are part of multiple administrative domains. Your current design (even with link encryption) means that any device connected to any of these networks can dictate the boundaries of the admin-local scope. Is it really desirable to trust all those devices to that extent? I think not. > > In addition to this fundamental concern, I have a few minor concerns > about the readability of the document. However, I seem to have mislaid > my notes during the holidays. Because this review is already late and > I'm on vacation, I will send the review now and follow up with the > minor concerns at a later date if I can find them when I return to the > office. If you find terms which are not defined in this draft, ietf-rol-trickle-mcast or RFC7346, I will be happy to extend the definitions of section 1.2. OK, I'll look for my notes. However, the most important aspect of my review is the security issue described above. ------=_NextPart_000_0A15_01D0268F.C1F40D00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDEwMjE4MjY0NlowIwYJKoZIhvcNAQkEMRYEFBHUnyKd9QjwzFVCJ6YwzF8H5P5QMHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADTVMi7u3AJNNjU85AbvpqwAlk/5So1gVDiNVxhyruonyoHAkFJc etZoVwus41/3QkSFshe8oQWqyZXZnWvhwqzHN8ayo8JHZIp4xhNarV7RcLLf1UkIr6WcnGDvUse1 HdeAbY0396Xz5f7jEv8DtAvq6J+x6jWWOs46j3Q5mN604y1Rou53wLp35eF+rfDPt/USfbiSbk2Z 3M+hGIuNVqk3QxmXSLySFtuMHHLWYEptb1WaQRveJgAmeL2p30n0ey5KIOs5gtKUxS8pS1CkRBzx ELxEszT25r3vhKG8tiQ1/Nv2NcRxu/xNskpXdSyALFBFqpNSfRtrS8a2kGTdxWsAAAAAAAA= ------=_NextPart_000_0A15_01D0268F.C1F40D00-- From nobody Fri Jan 2 16:39:49 2015 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 D84101A700D; Fri, 2 Jan 2015 16:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 txbms9XlsUlE; Fri, 2 Jan 2015 16:39:43 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B90E1A7002; Fri, 2 Jan 2015 16:39:41 -0800 (PST) X-AuditID: 12074423-f797b6d000000cfe-7a-54a73a4c7dd6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 23.77.03326.C4A37A45; Fri, 2 Jan 2015 19:39:40 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t030ddNl019831; Fri, 2 Jan 2015 19:39:39 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t030dXSi026213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jan 2015 19:39:35 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t030dXp0004364; Fri, 2 Jan 2015 19:39:33 -0500 (EST) Date: Fri, 2 Jan 2015 19:39:33 -0500 (EST) From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sfc-problem-statement.all@tools.ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixCmqrOtjtTzE4OlUcYu3X+6xW8z4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8a3Ba+ZCzamVjw6MYWpgfFzUBcj J4eEgInEm9Ov2CFsMYkL99azdTFycQgJLGaSWP9sFjOEs4FRYv6q7+wQzkEmiS1/z4C1CAnU SxzfeJEFxGYR0JJY8fcCmM0moCIx881GNhBbRCBBYnPnMbB6YQFbiYULe1hBbF4BR4n7X28y gdiiAjoSq/dPYYGIC0qcnPkEzGYGmrl8+jaWCYx8s5CkZiFJLWBkWsUom5JbpZubmJlTnJqs W5ycmJeXWqRrppebWaKXmlK6iREUbOwuyjsY/xxUOsQowMGoxMPLYbE8RIg1say4MvcQoyQH k5Iob4QxUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIL8veZSFCvCmJlVWpRfkwKWkOFiVx3k0/ +EKEBNITS1KzU1MLUotgsjIcHEoSvDdB9ggWpaanVqRl5pQgpJk4OEGG8wAN77AEquEtLkjM Lc5Mh8ifYlSUEuf9DtIsAJLIKM2D64Ulg1eM4kCvCPPmgrTzABMJXPcroMFMQIPzNy0GGVyS iJCSamCUyCi+aGzNx5XHUXDbsjSNbeoHA+mFzL62Hz+Utamf1vnNpj7x9cW4Y3WHyx/+8jTS /SjOoPO2y/Os1aecE9+WRs72qFzBzOvCtHrJ0+TDwjO+K2//OmeRQ0vjScVEg80KtZzTZ7xZ XmTs9X/TIYffAeEm+3s+mrV+fXjk9c1YwQnZ/coH/eYpsRRnJBpqMRcVJwIAjSbRd+ECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GlqII7wuCQg5o72jqxgVizm-Ijo Subject: [secdir] secdir review of draft-ietf-sfc-problem-statement-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: Sat, 03 Jan 2015 00:39:47 -0000 Hi all, Sorry this is a bit late. 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is not ready for publication. The document attempts to disclaim the need for a security considerations section by virtue of being a problem-statement only document. However, section 3 provides three components which are expected to be part of solutions to the problem, and the focus of future work in the working group. Even at this abstract level, there are still security considerations that can be made, and I'm sure I will not think of all of them during the course of this review. Additionally, there are sufficiently many grammar and language oddities and inconsistencies in the text to be distracting from the actual content of the document; I'll try to cover those at the end of this mail. Using multiple terms for the same concept doesn't help, either (as is disclaimed in the definitions section), but I understand how that is unavoidable in this case. To re-summarize the document (section 5 notwithstanding), it lays out some terminology and provides a list of many of the issues involved in setting up a complicated traffic processing scheme involving multiple network service functions (firewalls, traffic accelerators, load balancing, etc.) using current technologies. The difficulties largely stem from the tight coupling between the network topology and the way/order in which service functions are applied to traffic. Three components are discussed which will help break this coupling: a "service overlay", which allows for the service-function-chain topology to be decoupled from the network topology; "service classification" to control traffic flow on the service overlay topology; and "dataplane metadata" to convey the classification data (and other data). Here are the potential security considerations I came up with so far: * An error in service classification could lead to untrusted traffic flowing through a service function chain intended for trusted traffic only. In various hypothetical situations, this could lead to an attacker being able to execute privileged actions via a trusted service, execute a DoS attack against an internal service, etc. It is important for service classification to "fail safe" to avoid this class of issues. ("Failing safe" might or might not include just dropping such traffic.) * Similarly, errors in translating from an existing network/service topology to a separate service overlay (e.g., omission or addition of a firewall element) could lead to an attacker sending traffic in the real network to services which ought to be disallowed by the service overlay. * The dataplane metadata could open up a giant rabbit hole of information leakage. It is tempting to say that the metadata would only flow inside the network boundaries of a single (corporate) entity, but "SSL added and removed here :-)" should convince us that that's not a workable solution. Metadata could conceivably include the type of traffic, client information (i.e., personally identifying information), and more, some of which should receive protection from eavesdroppers on the dataplane which will not need to process the traffic in question. * Metadata can come from "external sources". Those sources should be trustworthy and verified, or attackers could send traffic where they oughtn't be able to. Here's the grammar and language issues that bothered me, roughly sorted with the more important ones coming first and otherwise in order of appearance: Section 3 has the text "the SFC working group will [...]", which seems more appropriate for a WG charter than an informational RFC. I see this had been brought up in discussion of the -03, but I did not see any obvious resolution in a quick skim. To be clear, I would be fine with something that didn't explicitly say what the WG would do, like "SFC may include solutions utilizing the following elements" or something similar. The document uses some acronyms that are not expanded. I expect most readers to be familiar with some, but not all, of: * Open Systems Interconnection * the OSI model, e.g., layer 3, layer 7, etc. (I had to think a moment about "L4-L7") * transmission control protocol * Virtual Local Area Network * Border Gateway Protocol * internet protocol * virtual private network * multiprotocol label switching * Wide Area Network * datacenter I can't find a parse that I'm happy with of the first paragraph of section 3.3. In particular, I'm not sure whether the leading "As such" is just a transition leading into a new sentence (equivalent to "Thus,"), in which case it should be offset by a comma, or if the "such" binds to "metadata" (equiavent to "Since such"). In the first version, I guess the metadata is supposed to be sent out-of-band and interpreted by functions along the service overlay, but I don't see how it would then *not* be used to control the route by which packets travel. In the latter version, the sentence is incomplete, since there's no dependent clause. In the third paragraph of section 3.3, the sense of the two things addressing issues seems reversed: "the decoupling of policy from the network topology" is a good thing, which will be obtained by using metadata; on the contrary, "the need for per-service function classification (and re-classification)" is a bad thing, namely the problem mentioned in section 2.10. I would probably resolve this with "[...] most notably by decoupling policy from the network topology, and by removing the need for per-service function classification (and re-classification) described in section 2.10." The abstract uses the phrase "ordered set of instances", but a set is explicitly unordered. Is there a better term to use, like "graph", "network", or "structure"? (The word "set" also appears in the second paragraph of the abstract, but may be more appropriate in that usage.) I'm not sure I'm interpreting the third paragraph of section 2.1 correctly -- is the issue that the network topology needs to change in front and behind of each service function, whenever a new service function is required? Or is it that the network topology must change before and after a new service function is introduced, in order to allow inserting the function without loss of serice? I would also find the last sentence more clear if reorderd to be "[...] all traffic often passes through the same strict order, whether a given service needs to be applied or not." In section 2.3, I don't understand what "constrained service function high availability" is. Is the issue just that the topology forces a situation which could be subject to reduced availability because certain high-availability techniques are not usable in that topology? The parenthetical in the abstract "such as firewalls, load balancers" is incorrect comma usage; I would tack on a ", etc." at the end. The second paragraph of the abstract is hard to parse; my best effort at cleaning it up is "The set of enabled service function chains reflects the service offerings of a given operator, and is designed in conjunction with application delivery, service, and network policy.", but I fear that has changed the meaning somehow. ("chains" needs to be plural, as does "reflects", but there's also a missing article for "operator service offerings", and the two "ands" in the final clause read oddly.) First paragraph of section 1, "requires" should be plural. (Comma after "functions" is optional, but might help readability.) Second paragraph of section 1, "the network topology" with the definite article. Also add a comma after "limits" so the parenthetical statement is properly offset by commas. The definition for "classification" doesn't seem grammatical. Perhaps, "Locally instantiated policy to match traffic flows to the appropriate outbound action(s)"? Additionally, should the definition be explicitly constrained to just forwarding actions (my proposal is not)? In the definition for "service function", is "One of" needed? Also, s/the Service Function/a Service Function/ in the last sentence of the first paragraph. In the second paragraph, there's no need to say "etc." when prefaced with "includes:" -- just say "and TCP optimization" (note s/optimizer/optimization/ for tense consistency). The definition for "Service Function Chain" is ... odd. I believe that "their ordering requirements" refers to the ordering of service functions within the chain, but "their ordering requirements that must be applied to packets" actually reads that the ordering requirements come from the set of service functions but is applied to the packets and/or frames. I would probably try to instead say something about "the constraints on the order in which service functions are applied to packets and/or frames". Additionally, "linear progression" is a bit vague; is the intention just to say that it may allow branching and need not be a complete/strict ordering (i.e., it could be a partial order)? In the definition for "Service Topology", the phrase "service overlay connectivity" is a little odd; I might reword to "connectivity of the service overlay". In section 2.1, remove the "the" from both "the service delivery" and "the flexibility". In the fourth paragraph of section 2.1, I'm failing to interpret the phrase "placement and service function selection taking into account network topology information is not viable." Is it adding anything that is not said prior to the colon in that sentence? In the fifth paragraph of section 2.1, add a comma before "forcing", to separate the independent and dependent clauses. In section 2.2, is "once installed, configured and deployed in production environments" needed? I might add "the" before "use" in the last line to aid readability, but it is probably not strictly necessary for correctness. In the second paragraph of section 2.3, add "the" before "network", and consider removing the comma after "alternate". In section 2.5, remove the space in "(re) classification". Use a comma after "i.e." as well as before. "increasingly less" is strange usage; consider just "decreasingly". Use "topology information" consistently (not "topological information"). Use a comma after the sentence adverb "furthermore". In section 2.6, add "network" before "under and overlays" (or mention that just "overlays" is valid usage in the definition in section 1.1). In section 2.7, are "such change" the VLAN changes or the service deployment changes? The current text has "such changes" bind to "changes to the service deployment", making the clause tautological. In section 2.8, "traffic" is singular, so "traverses" to match (first sentence). Consider expanding to "all service functions on that segment" as well, for clarity. Also consider adding "which" after "data traverses". In section 2.10, consider "between service functions" instead of "per service function", but in either case add a comma afterward. I would also clarify by adding "classification" in "the results from other service functions". In section 2.11, comma after "association" to separate the dependent and independent clauses. (Also, should it be the plural "associations"?) In section 3.1, the two "and"s is uncommon usage. Most such cases would be condensed to a comma-separated list, but here I would recommend """The service overlay provides service function connectivity, building "on top" of the existing network topology to allow operators to use whatever overlay or underlay they prefer for creating a path between service functions, and to locate service functions in the network as needed.""" In the last paragraph of section 3.1, hyphenate "service-specific information". In section 3.2, replace "service offered" with "the services offered". Section 3.3 is inconsistent about the whitespace in "dataplane" between section title and body. The second sentence of section 4 has what is basically a comma splice; I would fix it by "[...] exhaustive; rather, it [...]". The enumerated entries in section 4 are inconsistent about whether the working group name is expanded in the body text, and even whether it is referred to as a working group (or just a proper noun in its own right, viz. "LISP"). In section 4, item 3, add "The" before "NVO3 WG". -Ben Kaduk From nobody Sat Jan 3 06:19:28 2015 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 8DE701A1AA3; Sat, 3 Jan 2015 06:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 8OpK_SSzTsHx; Sat, 3 Jan 2015 06:19:25 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEFC1A1A8F; Sat, 3 Jan 2015 06:19:25 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so16281336lab.26; Sat, 03 Jan 2015 06:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JyUXrQoIuV10LoJL+q0agbzgwhLLnzN6bpubbPkT0Yc=; b=DRjglpsYBa19QBIsqiBC9F/+/oNzku4pxuCyWt1s/u46UXsJJZQZj1rkAWmktufJsB 4Pv66KU2YNSdLJx1b6VYuX9J1AenzhjkD0f5MZ9F7kFYwsWlLAAjy3hUqqKQ2PZIoVtF Zz7Imc1Va3GkcRHjrzeLq7XzJV9fFoDVEtw1Y6cV80Or/2WCzmBzo3BsBM+a21+ZOcz5 F8RbXJWOkGe8FovQqZbBWiSYAdVMY/UOQa7uYqACMV4MZjdYwLpJ+R5KdePIrgOUWRAt kWFia25KBRJFO7j8fAvesbfkifCSkYSV8eeH55uWoYV4kRpTFMpQCwvkWaLDbPbUbY13 TrlA== MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr81776484lbz.100.1420294763581; Sat, 03 Jan 2015 06:19:23 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Sat, 3 Jan 2015 06:19:23 -0800 (PST) In-Reply-To: References: Date: Sat, 3 Jan 2015 09:19:23 -0500 X-Google-Sender-Auth: PJE47MuVys-jRuZ_iUIASlLhGWw Message-ID: From: Barry Leiba To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xrktR4MF2x9evxwUEFTJ3eqyAGs Cc: draft-ietf-sfc-problem-statement.all@tools.ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-sfc-problem-statement-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: Sat, 03 Jan 2015 14:19:26 -0000 Hi, Ben. Just on the abbreviation-expansion point: > The document uses some acronyms that are not expanded. I expect most > readers to be familiar with some, but not all, of: > * Open Systems Interconnection > * the OSI model, e.g., layer 3, layer 7, etc. (I had to think a moment > about "L4-L7") > * transmission control protocol > * Virtual Local Area Network > * Border Gateway Protocol > * internet protocol > * virtual private network > * multiprotocol label switching > * Wide Area Network > * datacenter The RFC Editor has a list of abbreviations, on which those that are considered familiar enough not to need expansion are noted with "*": https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt One can find this list from the RFC Editor home page by clicking on the link to the style guide first. It probably should be linked somewhere that's more obvious for draft authors and reviewers to find. Anyway OSI, TCP, VLAN, BGP, IP, VPN, MPLS, and WAN are all flagged as not needing expansion, for what that's worth. Barry From nobody Sat Jan 3 08:44:18 2015 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 CE9871A8FD7 for ; Sat, 3 Jan 2015 08:44:16 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 TyD8wMsWyfem for ; Sat, 3 Jan 2015 08:44:15 -0800 (PST) Received: from smtp90.ord1c.emailsrvr.com (smtp90.ord1c.emailsrvr.com [108.166.43.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CF81A8FD5 for ; Sat, 3 Jan 2015 08:44:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C53DB3801AD; Sat, 3 Jan 2015 11:44:13 -0500 (EST) X-Virus-Scanned: OK Received: by smtp12.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 9A3163801BD; Sat, 3 Jan 2015 11:44:11 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Sat, 03 Jan 2015 16:44:13 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_C997F86D-4A79-4269-A6F0-339593EED6C5" Date: Sat, 3 Jan 2015 11:44:10 -0500 Message-Id: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> To: ietf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PR9D6KMXJNw375-pHznYmqJDVaE Cc: secdir@ietf.org Subject: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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: Sat, 03 Jan 2015 16:44:17 -0000 --Apple-Mail=_C997F86D-4A79-4269-A6F0-339593EED6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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.=20 This document is Ready with nits.=20 The document contains no issues from a security perspective as it is = only creating LSA=E2=80=99s for new types of route selection metrics, time instead of network hops.=20 The Nit that I have is the document in introduction says time is = important and the ability to select faster path has high economical gain.=20 The base time measurement unit in the new LSA=E2=80=99s is MICRO = seconds, there is no justification in the document that=20 says 1 micro second is granular enough for links of the near future = (over 100 Gbits+).=20 Olafur --Apple-Mail=_C997F86D-4A79-4269-A6F0-339593EED6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 Ready with = nits. 

The document contains no issues from a security = perspective as it is only creating LSA=E2=80=99s for new types of route = selection metrics,
time instead of network hops. 

The Nit that I = have is the document in introduction says time is important and the = ability to select faster path has high
economical gain. 
The base time = measurement unit in the new LSA=E2=80=99s is MICRO seconds, there is no = justification in the document that 
says 1 micro second is granular enough = for links of the near future (over 100 Gbits+). 

Olafur

= --Apple-Mail=_C997F86D-4A79-4269-A6F0-339593EED6C5-- From nobody Sat Jan 3 16:48:18 2015 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 A0ED51AC3B9; Sat, 3 Jan 2015 16:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 kNDSO3pH2TMr; Sat, 3 Jan 2015 16:48:16 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CBA1A1A87; Sat, 3 Jan 2015 16:48:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y7ZMa-0000Gi-U9; Sun, 04 Jan 2015 00:48:13 +0000 Date: Sun, 04 Jan 2015 09:48:11 +0900 Message-ID: From: Randy Bush To: Olafur Gudmundsson In-Reply-To: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yh2A-S2j8oud93WH3l28ozDMhQM Cc: ietf , secdir@ietf.org Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 04 Jan 2015 00:48:17 -0000 > The document contains no issues from a security perspective as it is > only creating LSA=E2=80=99s for new types of route selection metrics, time > instead of network hops. and the new lsas could not be used in path shortening attacks, right? randy From nobody Sat Jan 3 22:56:52 2015 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 83B361A6FEF; Sat, 3 Jan 2015 22:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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 4sfXZxn5IRmx; Sat, 3 Jan 2015 22:56:48 -0800 (PST) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E8C1A6FEE; Sat, 3 Jan 2015 22:56:48 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t046ulBU008816; Sun, 4 Jan 2015 01:56:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1420354607; bh=j7IBLFvCbUrnqsYF5HSs0n0i0vXIme1llXakV8u+Kgg=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=L3h2WkSAaEvIB+bp+IT3Oc/Oeoae7dozxWRejeBlEdpV4GJjg1RdcZk2XFZrxstpx T02WPvPyP806gkDyQT05YlHbjF6hzg8daFS0vFtfzafZm2mFlnud1zuYYTTvgmoUBc IvC8rLNWEuSTiAYNK2aG/m64mcH39XvwOEo24wAk= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t046v00f005364; Sun, 4 Jan 2015 01:57:00 -0500 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.03.0210.002; Sun, 4 Jan 2015 01:56:46 -0500 From: Chris Inacio To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-pcp-server-selection.all@tools.ietf.org" Thread-Topic: sector review of draft-ietf-pcp-server-selection-07 Thread-Index: AQHQJ+uaAUxKUQpnyUK05uEkCW52tA== Date: Sun, 4 Jan 2015 06:56:46 +0000 Message-ID: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.96.75] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/aOzZ8bsFDPtjohqophyRRmo67_w Subject: [secdir] sector review of draft-ietf-pcp-server-selection-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: Sun, 04 Jan 2015 06:56:50 -0000 DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5 IGRpcmVjdG9yYXRl4oCZcyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiB3aXRoIHRoZSBpbnRlbnQgb2YgaW1wcm92aW5nIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBh bmQgY29uc2lkZXJhdGlvbnMgaW4gSUVURiBkcmFmdHMuICBDb21tZW50cyBub3QgYWRkcmVzc2Vk IGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVkZWQgaW4gQUQgcmV2aWV3cyBkdXJpbmcgdGhlIElF U0cgcmV2aWV3LiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0K R2VuZXJhbGx5IHRoZSBkb2N1bWVudCBpcyBpbiBnb29kIHNoYXBlLCBhbmQgSSB3b3VsZCBsaWtl IHRvIHNlZSBvbmUgbWlub3IgaXNzdWUgYXQgbGVhc3QgY29tbWVudGVkIHVwb24uDQoNCkkgaGF2 ZSBhIHNpbmdsZSBzZWN1cml0eSByZWxhdGVkIGNvbW1lbnQgb24gdGhpcyBkcmFmdDsgdGhlIGxh c3Qgc2VudGVuY2Ugb2Ygc2VjdGlvbiAzOg0KDQo+IEZvciBlZmZpY2llbmN5LCB0aGUgUENQIGNs aWVudCBTSE9VTEQgdXNlIHRoZSBzYW1lIE1hcHBpbmcgTm9uY2UgZm9yDQo+ICAgcmVxdWVzdHMg c2VudCB0byBhbGwgSVAgYWRkcmVzc2VzIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBQQ1Agc2VydmVy Lg0KDQpOb3JtYWxseSwgSSB3b3VsZCBzaW1wbHkgc2F5IHRoaXMgaXMgYSBjcmF6eSByZWNvbW1l bmRhdGlvbi4gIEJ1dCBhZnRlciBsb29raW5nIGEgbGl0dGxlIGludG8gd2hhdCB0aGUgTm9uY2Ug aXMgdXNlZCBmb3IgaW4gdGhlIFBDUCBwcm90b2NvbCwgSSBhbSBzbGlnaHRseSBsZXNzIGRpc3Ry YXVnaHQuICBUaGlzIE5vbmNlIGRvZXMgbm90IGFwcGVhciB0byBuZWNlc3NhcmlseSBwcm92aWRl IGFueSBodWdlIGFtb3VudCBvZiBzZWN1cml0eSBleGNlcHQgYWxsb3dpbmcgdGhlIGNsaWVudCB0 byBnZW5lcmF0ZSBhIHVuaXF1ZSB0b2tlbiBwZXIgUENQIHNlcnZlci4gIFByZXN1bWFibHkgdGhl cmUgaXMgYSBnZW5lcmFsIE1JVE0gYXR0YWNrIG9uIHRoZSBQQ1AgcHJvdG9jb2wgcmVsYXRlZCB0 byB0aGUgTm9uY2UgYXMgYSB0cmFuc2FjdGlvbiBJRCB3aGljaCBpcyBwcmV2ZW50ZWQgYnkgdXNp bmcgb3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzLCBUTFMsIGV0Yy4gIChBbmQgYW5vdGhlciB3ZWxs IGtub3duIGF0dGFjayB3aXRoIHRoZSBUSElSRF9QQVJUWSBvcHRpb24gYW5kIGxhY2sgb2YgYXV0 aGVudGljYXRpb27igKYpIFRoZXJlZm9yZSwgdGhpcyBOb25jZSBpcyBjcml0aWNhbCBhcyBhIHN5 bmNocm9uaXphdGlvbiBwb2ludCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBwb3RlbnRpYWwg UENQIHNlcnZlci4gIEl0IHdvdWxkIGJlIG5pY2UgKGFzc3VtaW5nIGFsbCB0aGF0IGlzIGNvcnJl Y3QpIHRvIG1ha2UgdGhhdCBjbGVhciBpbiB0aGUgZG9jdW1lbnQsIGVzcGVjaWFsbHkgd2l0aCBh IHJlY29tbWVuZGF0aW9uIHRvIHJldXNlIHRoZSBOb25jZS4NCg0KDQpOaXRzOg0KDQpJbiBGaWd1 cmUgMSwgdGhlIGxpbmVzIGFyZSBub3QgYWxpZ25lZCB0byB0aGUg4oCcK+KAnSBvbiB0aGUgZGlh Z3JhbXMuDQoNCkluIEZpZ3VyZSAzLCDigJxydHIx4oCdIGlzIG1pc3NpbmcgYSDigJwr4oCdIG9u IHRoZSByaWdodCBzaWRlIGNvbm5lY3Rpb24gZnJvbSB0aGUgdG9wLg0KDQoNCi0tDQpDaHJpcyBJ bmFjaW8NCmluYWNpb0BjZXJ0Lm9yZw0KDQoNCg0K From nobody Sun Jan 4 19:29:20 2015 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 EAF5B1A1A2D; Sun, 4 Jan 2015 19:29:12 -0800 (PST) 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 dYVjNrAQEyPv; Sun, 4 Jan 2015 19:29:10 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BB81A1A33; Sun, 4 Jan 2015 19:29:10 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id fl12so11681975pdb.39; Sun, 04 Jan 2015 19:29:09 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=8/avYNjhpQuOrDNdQk463TwD/gJrjx3I/2h5Cme7U0Q=; b=OvZKlvGuyqvwI2yigb9HafMpdoB6/szcC7xe5a1ZgdRLR09fk29Qr44XnyX+yxjcFW BMb5pfFHvAgads8VKRPeXLh0KO25cngNLtxYsB0L24cf3ZdjOb4OID4j7VDTZVPZfs1B /V84p4QXX1+Xb2kiLU/MkX3Ux6zmnhbxL5+f8UAKhVw2owTjWHf/3TqMicLKbXpPzO+n WpmML+tuxnW2duVtXl+8IUhJsu8pMOVPtkfW0w4JxmovSP6oTFtagoqhGcpotThUJmzg UVOKUMgeAufQJXKxDV4JZHLzhEHBb6TlLLMNldftFGILTPCnwCXFix/ea/h9pzZXrt1m FWvQ== X-Received: by 10.68.231.71 with SMTP id te7mr57828500pbc.38.1420428549482; Sun, 04 Jan 2015 19:29:09 -0800 (PST) Received: from ?IPv6:2601:9:3400:6c:4d19:ed9d:99ba:fad9? ([2601:9:3400:6c:4d19:ed9d:99ba:fad9]) by mx.google.com with ESMTPSA id th7sm53168899pac.47.2015.01.04.19.29.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 19:29:08 -0800 (PST) Message-ID: <54AA04FA.1040406@gmail.com> Date: Sun, 04 Jan 2015 19:28:58 -0800 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian Weis , The IESG , secdir@ietf.org, draft-ietf-radext-dynamic-discovery.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LKP4islBILJOiJl7iac9EAMo9iY Subject: Re: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12 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, 05 Jan 2015 03:29:13 -0000 Thanks you for the detailed review Brian. We'll have a look and come back to these shortly. - Jouni 12/24/2014, 1:05 PM, Brian Weis kirjoitti: > 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document specifies a means to find authoritative RADIUS servers for a given realm. This can be useful when authenticating/authorizing devices within a roaming consortium (e.g., eduroam). An authoritative RADIUS client trying to authenticate/authorize a host or perform accounting for that host finds a RADIUS server by querying DNS for service records defined in this document. Once a candidate sever has been found in DNS, the querier initiates a RADIUS protocol to it protected by TLS, authorizes it based on information in its certificate, and then RADIUS happens in the usual fashion. The document is almost ready for publication, in my opinion. > > There’s not much background given, and having an overview of the solution architecture in the Introduction would be useful. I.e., a description and picture showing the actors and the communication flows between them. I don’t have complete confidence that I correctly understood which actors are involved in the RASIUS/TLS transaction -- in some sections it seems that RADIUS clients are initiating requests and sometimes RADIUS servers and I thought only clients contacted servers. An overview of the actors would probably have clarified that. > > If I understand correctly how roaming consortiums currently work today, a RADIUS client within a consortium needing to make a AAA call to a RADIUS server in another realm does not contact the server directly. Instead, it routes the request through a hierarchy of RADIUS servers following roots of trust. The trust model in this document seems to be bypass the roots of trust, where the client directly contacts the server. This seems to be discussed in the Section 6 (Privacy Considerations) discussion of “clearinghouses", but if the trust model is changed, this is a bigger impact than privacy so ought to be discussed explicitly someplace in the document. > > Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the point that certificate based cipher suites need to be used because there won’t be any pre-distributed secret key material available. That’s good advice. I think the section should also give advice on choosing trust roots. This is important because the identity of the server was gotten in an untrusted manner (from unsecured DNS), and the certificate it presents contains information used for authorization of a server (i.e., SubjectAltName). If a RADIUS client were to accept a certificate signed by a wide range of trust roots (e.g, the set of roots used by browsers, where the trustability of many CAs in the hierarchy is unknown) then the RADIUS client would be ill advised to trust authorization information claims in the hierarchy. On the other hand, if the trust roots were restricted to a set of highly trusted trust roots maintained by the consortium, then the authorization information in the certificate would be trustable. This should be explained. > > Section 2.2 defines the NAIRealm name as a form of otherName. This makes sense. But there is also a paragraph discussing sRVName, which is confusing. I think it’s clarifying who sRVName isn’t applicable; it would be good state that plainly at the beginning of the paragraph. > > Section 5 (first paragraph) makes the point that the information gotten from DNS can’t be trusted. But I would suggest a slight rewording: s/can not be trusted/is not sufficient to identify an authorized server/. > > Brian > From nobody Sun Jan 4 20:48:20 2015 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 4B4F51A1A7F for ; Sun, 4 Jan 2015 20:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD3K6xriSUW7 for ; Sun, 4 Jan 2015 20:48:16 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864921A1ADF for ; Sun, 4 Jan 2015 20:48:16 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t054mDs6025020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 04:48:14 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t054mCO6021412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2015 04:48:12 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t054mB85020774; Mon, 5 Jan 2015 04:48:12 GMT Received: from dhcp-rmdc-twvpn-2-vpnpool-10-159-73-210.vpn.oracle.com (/10.159.73.210) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Jan 2015 20:48:11 -0800 Message-ID: <54AA17B0.40500@oracle.com> Date: Sun, 04 Jan 2015 21:48:48 -0700 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-aqm-recommendation.all@tools.ietf.org References: <544F3820.6040505@oracle.com> In-Reply-To: <544F3820.6040505@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GHk8PwCqNgHZME2vXtoYajxrnm8 Subject: [secdir] Review of draft-ietf-aqm-recommendation-08 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, 05 Jan 2015 04:48:19 -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 proposed BCP draft provides guidance on various ways to improve network performance over the Internet through Active Queue Management (AQM). The draft describes various techniques to avoid network failure due to congestion, congestion itself, and network latencies. The security considerations section does exist and discloses that the draft does not impose any new security considerations beyond what is currently vulnerable to DoS attacks, in fact AQM may help in mitigating against some of these attacks. However, the draft explains that not all DoS attacks can be avoided and suggests that further investigation is required to find out how to help prevent said attacks. I believe that these assertions are correct. General comments: A well written and thorough document. Thank you. Editorial comments: s/> class of/class of/ s/connection preventing/connections, preventing/ s/devices deploy/devices that deploy/ Shawn. -- From nobody Sun Jan 4 20:49:06 2015 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 C80EB1A1ADF; Sun, 4 Jan 2015 20:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3] 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 1bYfhKhWcX62; Sun, 4 Jan 2015 20:48:56 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 628F91A1A7F; Sun, 4 Jan 2015 20:48:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3F19B2240592; Mon, 5 Jan 2015 05:48:25 +0100 (CET) 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 GZWdrYvthrMN; Mon, 5 Jan 2015 05:48:23 +0100 (CET) Received: from [192.168.20.49] (198-84-181-115.cpe.teksavvy.com [198.84.181.115]) by power.freeradius.org (Postfix) with ESMTPSA id 8035B2240102; Mon, 5 Jan 2015 05:48:21 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Sun, 4 Jan 2015 23:48:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Weis X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vCzzGIXJ0SdffI02n2J7z7CyOag Cc: The IESG , draft-ietf-radext-dynamic-discovery.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12 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, 05 Jan 2015 04:49:00 -0000 On Dec 24, 2014, at 4:05 PM, Brian Weis wrote: I=92m not the document author, but I can help give some clarification. > There=92s not much background given, and having an overview of the = solution architecture in the Introduction would be useful. I.e., a = description and picture showing the actors and the communication flows = between them. The current roaming behaviour is discussed in the NAI document, = Section 3. Unfortunately, it also assumes some familiarity with the = field. http://tools.ietf.org/html/draft-ietf-radext-nai-15#section-3 Perhaps the simplest explanation is that RADIUS is client-server. = Clients request authentication on behalf of users, and servers = authenticate the users. The key thing is that historically, proxying = has been static, and provisioning of proxy configuration has been = entirely outside of the protocol. i.e. proxies operate by consensus and = habit, not by standard behaviour. A long description of the Eduroam consortium is available as an = individual draft: http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-04 However, *commercial* proxies do not operate in the eduroam model. = Commercial proxies are largely =93star=94 configurations. An = interconnect company sits at the centre of a star. It may connect to = one or more other interconnect providers. Routes are largely static, = and are usually updated by hand, after legal contracts have been = exchanged. This document is standardizing provisioning of RADIUS proxying, via = dynamic methods. > I don=92t have complete confidence that I correctly understood which = actors are involved in the RASIUS/TLS transaction -- in some sections it = seems that RADIUS clients are initiating requests and sometimes RADIUS = servers and I thought only clients contacted servers. An overview of the = actors would probably have clarified that. Clients are the only ones initiating requests. In some cases, the = system running RADIUS can behave as a client or as a server, depending = on it=92s needs. That makes it more complicated. > If I understand correctly how roaming consortiums currently work = today, a RADIUS client within a consortium needing to make a AAA call to = a RADIUS server in another realm does not contact the server directly. s/does not/may not/ > Instead, it routes the request through a hierarchy of RADIUS servers = following roots of trust. That=92s how eduroam works. Commercial proxies are configured = differently. However, they both operate on a =93fire and forget=94 model. A RADIUS = server which wants to proxy a request somehow (magically, almost) = determines which upstream server to use. The =93magic=94 part of that = process is what the dynamic discovery document is trying to standardize. > Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the = point that certificate based cipher suites need to be used because there = won=92t be any pre-distributed secret key material available. That=92s = good advice. I think the section should also give advice on choosing = trust roots. This is important because the identity of the server was = gotten in an untrusted manner (from unsecured DNS), and the certificate = it presents contains information used for authorization of a server = (i.e., SubjectAltName). If a RADIUS client were to accept a certificate = signed by a wide range of trust roots (e.g, the set of roots used by = browsers, where the trustability of many CAs in the hierarchy is = unknown) then the RADIUS client would be ill advised to trust = authorization information claims in the hierarchy. Current RADIUS practice uses a limited set of CAs. Generally, only = one. This use-case is *very* different than that for browsers. This = document should make that clearer. Shipping a RADIUS server (or client) = with a list of pre-configured CAs is a *very bad* idea. RFC 6614 = (RADIUS over TLS) should probably have had such statements. RFC 7360 = (RADIUS over DTLS) has some related text which would be useful here: https://tools.ietf.org/html/rfc7360 Section 10.4: ... Therefore, clients SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer. Instead, the clients SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator. This scenario is the opposite of web browsers, where they are pre- configured with many known CAs. The goal there is security from third-party observers, but also the ability to communicate with any unknown site that presents a signed certificate. In contrast, the goal of RADIUS/DTLS is both security from third-party observers and the ability to communicate with only a small set of well-known servers. > On the other hand, if the trust roots were restricted to a set of = highly trusted trust roots maintained by the consortium, then the = authorization information in the certificate would be trustable. This = should be explained. Generally there=92s only one root CA for a consortium. I=92m not sure = what the use-case would be for multiple root CAs. Alan DeKok. From nobody Sun Jan 4 23:34:59 2015 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 2E9B11A1DFA; Sun, 4 Jan 2015 23:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEa4d5JR3PfY; Sun, 4 Jan 2015 23:34:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841391A1BED; Sun, 4 Jan 2015 23:34:51 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 56EBBC0106; Mon, 5 Jan 2015 08:34:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2EC12C807C; Mon, 5 Jan 2015 08:34:49 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.56]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Mon, 5 Jan 2015 08:34:49 +0100 From: To: Chris Inacio , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-pcp-server-selection.all@tools.ietf.org" Thread-Topic: sector review of draft-ietf-pcp-server-selection-07 Thread-Index: AQHQJ+uaAUxKUQpnyUK05uEkCW52tJyxIxpQ Date: Mon, 5 Jan 2015 07:34:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330048DEF48@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> In-Reply-To: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.201820 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vPwe6DSpat39pO7Q13Guxo_dMZ8 Subject: Re: [secdir] sector review of draft-ietf-pcp-server-selection-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: Mon, 05 Jan 2015 07:34:54 -0000 RGVhciBDaHJpcywNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KTm9uY2UgdmFsaWRh dGlvbiBjaGVja3MgYXJlIHVzZWQgd2hlbiBvcGVyYXRpbmcgaW4gdGhlIHNpbXBsZSB0aHJlYXQg bW9kZWwgYXMgZGlzY3Vzc2VkIGluIFJGQzY4ODcuIEFkZGluZyBhIHJlZmVyZW5jZSB0byBzZWN0 aW9uIDE4LjEgb2YgUkZDNjg4NyB3b3VsZCBiZSBzdWZmaWNpZW50IElNSE8uIFBDUCBhdXRoZW50 aWNhdGlvbiB3aWxsIGJlIG5lZWRlZCBpZiBvcGVyYXRpbmcgaW4gdGhlIEFkdmFuY2VkIFRocmVh dCBNb2RlbC4gDQoNCk9MRDoNCkZvciBlZmZpY2llbmN5LCB0aGUgUENQIGNsaWVudCBTSE9VTEQg dXNlIHRoZSBzYW1lIE1hcHBpbmcgTm9uY2UgZm9yIHJlcXVlc3RzIHNlbnQgdG8gYWxsIElQIGFk ZHJlc3NlcyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgUENQIHNlcnZlci4gDQoNCk5FVzoNCiBGb3Ig ZWZmaWNpZW5jeSwgdGhlIFBDUCBjbGllbnQgU0hPVUxEIHVzZSB0aGUgc2FtZSBNYXBwaW5nIE5v bmNlIGZvciByZXF1ZXN0cyBzZW50IHRvIGFsbCBJUCBhZGRyZXNzZXMgYmVsb25naW5nIHRvIHRo ZSBzYW1lIFBDUCBzZXJ2ZXIuIEFzIGEgcmVtaW5kZXIsIG5vbmNlIHZhbGlkYXRpb24gY2hlY2tz IGFyZSBwZXJmb3JtZWQgd2hlbiBvcGVyYXRpbmcgaW4gdGhlIFNpbXBsZSBUaHJlYXQgTW9kZWwg KFNlY3Rpb24gMTguMSBvZiBbUkZDNjg4N10pIHRvIGRlZmVuZCBhZ2FpbnN0IHNvbWUgb2ZmLXBh dGggYXR0YWNrcy4gIA0KDQpCZXR0ZXI/DQoNCkkgYWxyZWFkeSBmaXhlZCB0aGUgbml0cyBpbiBt eSBsb2NhbCBjb3B5Lg0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IENocmlzIEluYWNpbyBbbWFpbHRvOmluYWNpb0BjZXJ0 Lm9yZ10gDQpFbnZvecOpwqA6IGRpbWFuY2hlIDQgamFudmllciAyMDE1IDA3OjU3DQrDgMKgOiBz ZWNkaXJAaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGNwLXNlcnZlci1zZWxl Y3Rpb24uYWxsQHRvb2xzLmlldGYub3JnDQpPYmpldMKgOiBzZWN0b3IgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtcGNwLXNlcnZlci1zZWxlY3Rpb24tMDcNCg0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl4oCZcyBvbmdvaW5n IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0 aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBpbnRlbnQgb2Yg aW1wcm92aW5nIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBhbmQgY29uc2lkZXJhdGlvbnMgaW4gSUVU RiBkcmFmdHMuICBDb21tZW50cyBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5j bHVkZWQgaW4gQUQgcmV2aWV3cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiAgRG9jdW1lbnQgZWRp dG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2Ug YW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KR2VuZXJhbGx5IHRoZSBkb2N1bWVudCBp cyBpbiBnb29kIHNoYXBlLCBhbmQgSSB3b3VsZCBsaWtlIHRvIHNlZSBvbmUgbWlub3IgaXNzdWUg YXQgbGVhc3QgY29tbWVudGVkIHVwb24uDQoNCkkgaGF2ZSBhIHNpbmdsZSBzZWN1cml0eSByZWxh dGVkIGNvbW1lbnQgb24gdGhpcyBkcmFmdDsgdGhlIGxhc3Qgc2VudGVuY2Ugb2Ygc2VjdGlvbiAz Og0KDQo+IEZvciBlZmZpY2llbmN5LCB0aGUgUENQIGNsaWVudCBTSE9VTEQgdXNlIHRoZSBzYW1l IE1hcHBpbmcgTm9uY2UgZm9yDQo+ICAgcmVxdWVzdHMgc2VudCB0byBhbGwgSVAgYWRkcmVzc2Vz IGJlbG9uZ2luZyB0byB0aGUgc2FtZSBQQ1Agc2VydmVyLg0KDQpOb3JtYWxseSwgSSB3b3VsZCBz aW1wbHkgc2F5IHRoaXMgaXMgYSBjcmF6eSByZWNvbW1lbmRhdGlvbi4gIEJ1dCBhZnRlciBsb29r aW5nIGEgbGl0dGxlIGludG8gd2hhdCB0aGUgTm9uY2UgaXMgdXNlZCBmb3IgaW4gdGhlIFBDUCBw cm90b2NvbCwgSSBhbSBzbGlnaHRseSBsZXNzIGRpc3RyYXVnaHQuICBUaGlzIE5vbmNlIGRvZXMg bm90IGFwcGVhciB0byBuZWNlc3NhcmlseSBwcm92aWRlIGFueSBodWdlIGFtb3VudCBvZiBzZWN1 cml0eSBleGNlcHQgYWxsb3dpbmcgdGhlIGNsaWVudCB0byBnZW5lcmF0ZSBhIHVuaXF1ZSB0b2tl biBwZXIgUENQIHNlcnZlci4gIFByZXN1bWFibHkgdGhlcmUgaXMgYSBnZW5lcmFsIE1JVE0gYXR0 YWNrIG9uIHRoZSBQQ1AgcHJvdG9jb2wgcmVsYXRlZCB0byB0aGUgTm9uY2UgYXMgYSB0cmFuc2Fj dGlvbiBJRCB3aGljaCBpcyBwcmV2ZW50ZWQgYnkgdXNpbmcgb3RoZXIgc2VjdXJpdHkgcHJvdG9j b2xzLCBUTFMsIGV0Yy4gIChBbmQgYW5vdGhlciB3ZWxsIGtub3duIGF0dGFjayB3aXRoIHRoZSBU SElSRF9QQVJUWSBvcHRpb24gYW5kIGxhY2sgb2YgYXV0aGVudGljYXRpb27igKYpIFRoZXJlZm9y ZSwgdGhpcyBOb25jZSBpcyBjcml0aWNhbCBhcyBhIHN5bmNocm9uaXphdGlvbiBwb2ludCBiZXR3 ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBwb3RlbnRpYWwgUENQIHNlcnZlci4gIEl0IHdvdWxkIGJl IG5pY2UgKGFzc3VtaW5nIGFsbCB0aGF0IGlzIGNvcnJlY3QpIHRvIG1ha2UgdGhhdCBjbGVhciBp biB0aGUgZG9jdW1lbnQsIGVzcGVjaWFsbHkgd2l0aCBhIHJlY29tbWVuZGF0aW9uIHRvIHJldXNl IHRoZSBOb25jZS4NCg0KDQpOaXRzOg0KDQpJbiBGaWd1cmUgMSwgdGhlIGxpbmVzIGFyZSBub3Qg YWxpZ25lZCB0byB0aGUg4oCcK+KAnSBvbiB0aGUgZGlhZ3JhbXMuDQoNCkluIEZpZ3VyZSAzLCDi gJxydHIx4oCdIGlzIG1pc3NpbmcgYSDigJwr4oCdIG9uIHRoZSByaWdodCBzaWRlIGNvbm5lY3Rp b24gZnJvbSB0aGUgdG9wLg0KDQoNCi0tDQpDaHJpcyBJbmFjaW8NCmluYWNpb0BjZXJ0Lm9yZw0K DQoNCg0K From nobody Mon Jan 5 02:10:25 2015 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 4CC281A1BD2; Sun, 4 Jan 2015 22:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgf9kggOZTy0; Sun, 4 Jan 2015 22:24:57 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D6D1A1BFA; Sun, 4 Jan 2015 22:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3630; q=dns/txt; s=iport; t=1420439097; x=1421648697; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QlB6arKEKiRkJOsaEZ2VMd6Ya+Eca+d9838eHc3Wghc=; b=hhZ3GXN+CFyHgPT6Lw45z3OcyVBQINKil23ZRAAJ08D+kzrEiJrpdVr8 HVuMJuM9HJ+Tej8smV7QSrohd/zpusnrTWr2KWcRW+2+uijtdoRfsIJ5j KkCu+9g9s21zyQYpuVx08jLVmo3HCd0Q9x/4LfjIzKplwxH+i5OUi3aOz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFACgtqlStJA2N/2dsb2JhbABcgwaBKgSDAcBziBYCHGgWAQEBAQF9hAwBAQEDASMRUQQCAQYCEQQBAQMCBh0DAgICMBQBCAgCBAESCIgcCItNnGiTMgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIY4lFiIGgmIugRMBBI4VigCCZY1eIoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,698,1413244800"; d="scan'208";a="110294516" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 05 Jan 2015 06:24:56 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t056OuO6012351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 06:24:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.160]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 00:24:56 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Chris Inacio , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-pcp-server-selection.all@tools.ietf.org" Thread-Topic: sector review of draft-ietf-pcp-server-selection-07 Thread-Index: AQHQJ+uaAUxKUQpnyUK05uEkCW52tJyxD3qw Date: Mon, 5 Jan 2015 06:24:55 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35526351@xmb-rcd-x10.cisco.com> References: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> In-Reply-To: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hPLXTGZCMmgTYANg8CnBjYA1B5I X-Mailman-Approved-At: Mon, 05 Jan 2015 02:10:24 -0800 Subject: Re: [secdir] sector review of draft-ietf-pcp-server-selection-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: Mon, 05 Jan 2015 06:24:59 -0000 SGkgQ2hyaXMsDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDaHJpcyBJbmFjaW8gW21haWx0 bzppbmFjaW9AY2VydC5vcmddDQo+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAwNCwgMjAxNSAxMjoy NyBQTQ0KPiBUbzogc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBkcmFmdC1pZXRmLXBj cC1zZXJ2ZXItDQo+IHNlbGVjdGlvbi5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogc2Vj dG9yIHJldmlldyBvZiBkcmFmdC1pZXRmLXBjcC1zZXJ2ZXItc2VsZWN0aW9uLTA3DQo+IA0KPiAN Cj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRl4oCZcyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQo+IGNvbW1lbnRz IHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBpbnRlbnQgb2YgaW1wcm92aW5nIHNlY3VyaXR5IHJlcXVp cmVtZW50cw0KPiBhbmQgY29uc2lkZXJhdGlvbnMgaW4gSUVURiBkcmFmdHMuICBDb21tZW50cyBu b3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkNCj4gYmUgaW5jbHVkZWQgaW4gQUQgcmV2aWV3 cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cNCj4gY2hh aXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy4NCj4gDQo+IEdlbmVyYWxseSB0aGUgZG9jdW1lbnQgaXMgaW4gZ29vZCBz aGFwZSwgYW5kIEkgd291bGQgbGlrZSB0byBzZWUgb25lIG1pbm9yDQo+IGlzc3VlIGF0IGxlYXN0 IGNvbW1lbnRlZCB1cG9uLg0KPiANCj4gSSBoYXZlIGEgc2luZ2xlIHNlY3VyaXR5IHJlbGF0ZWQg Y29tbWVudCBvbiB0aGlzIGRyYWZ0OyB0aGUgbGFzdCBzZW50ZW5jZSBvZg0KPiBzZWN0aW9uIDM6 DQo+IA0KPiA+IEZvciBlZmZpY2llbmN5LCB0aGUgUENQIGNsaWVudCBTSE9VTEQgdXNlIHRoZSBz YW1lIE1hcHBpbmcgTm9uY2UgZm9yDQo+ID4gICByZXF1ZXN0cyBzZW50IHRvIGFsbCBJUCBhZGRy ZXNzZXMgYmVsb25naW5nIHRvIHRoZSBzYW1lIFBDUCBzZXJ2ZXIuDQo+IA0KPiBOb3JtYWxseSwg SSB3b3VsZCBzaW1wbHkgc2F5IHRoaXMgaXMgYSBjcmF6eSByZWNvbW1lbmRhdGlvbi4gIEJ1dCBh ZnRlcg0KPiBsb29raW5nIGEgbGl0dGxlIGludG8gd2hhdCB0aGUgTm9uY2UgaXMgdXNlZCBmb3Ig aW4gdGhlIFBDUCBwcm90b2NvbCwgSSBhbQ0KPiBzbGlnaHRseSBsZXNzIGRpc3RyYXVnaHQuICBU aGlzIE5vbmNlIGRvZXMgbm90IGFwcGVhciB0byBuZWNlc3NhcmlseSBwcm92aWRlDQo+IGFueSBo dWdlIGFtb3VudCBvZiBzZWN1cml0eSBleGNlcHQgYWxsb3dpbmcgdGhlIGNsaWVudCB0byBnZW5l cmF0ZSBhIHVuaXF1ZQ0KPiB0b2tlbiBwZXIgUENQIHNlcnZlci4gIFByZXN1bWFibHkgdGhlcmUg aXMgYSBnZW5lcmFsIE1JVE0gYXR0YWNrIG9uIHRoZSBQQ1ANCj4gcHJvdG9jb2wgcmVsYXRlZCB0 byB0aGUgTm9uY2UgYXMgYSB0cmFuc2FjdGlvbiBJRCB3aGljaCBpcyBwcmV2ZW50ZWQgYnkgdXNp bmcNCj4gb3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzLCBUTFMsIGV0Yy4gIChBbmQgYW5vdGhlciB3 ZWxsIGtub3duIGF0dGFjayB3aXRoIHRoZQ0KPiBUSElSRF9QQVJUWSBvcHRpb24gYW5kIGxhY2sg b2YgYXV0aGVudGljYXRpb27igKYpIFRoZXJlZm9yZSwgdGhpcyBOb25jZSBpcw0KPiBjcml0aWNh bCBhcyBhIHN5bmNocm9uaXphdGlvbiBwb2ludCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBw b3RlbnRpYWwgUENQDQo+IHNlcnZlci4gIEl0IHdvdWxkIGJlIG5pY2UgKGFzc3VtaW5nIGFsbCB0 aGF0IGlzIGNvcnJlY3QpIHRvIG1ha2UgdGhhdCBjbGVhciBpbg0KPiB0aGUgZG9jdW1lbnQsIGVz cGVjaWFsbHkgd2l0aCBhIHJlY29tbWVuZGF0aW9uIHRvIHJldXNlIHRoZSBOb25jZS4NCg0KV2Ug d2lsbCBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gdG8gYWRkcmVzcyB0aGlzIGNvbW1lbnQ6DQpUaGUgTWFwcGluZyBOb25jZSB2YWx1ZSBv bmx5IHByb3ZpZGVzIHByb3RlY3Rpb24gYWdhaW5zdCBvZmYtcGF0aCBhdHRhY2tzIGFuZCBQQ1Ag YXV0aGVudGljYXRpb24gW0ktRC5pZXRmLXBjcC1hdXRoZW50aWNhdGlvbl0gbXVzdCANCmJlIHVz ZWQgdG8gZGVmZW5kIGFnYWluc3QgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrLg0KDQo+IA0KPiAN Cj4gTml0czoNCj4gDQo+IEluIEZpZ3VyZSAxLCB0aGUgbGluZXMgYXJlIG5vdCBhbGlnbmVkIHRv IHRoZSDigJwr4oCdIG9uIHRoZSBkaWFncmFtcy4NCj4gDQo+IEluIEZpZ3VyZSAzLCDigJxydHIx 4oCdIGlzIG1pc3NpbmcgYSDigJwr4oCdIG9uIHRoZSByaWdodCBzaWRlIGNvbm5lY3Rpb24gZnJv bSB0aGUgdG9wLg0KDQpUaGFua3MsIHdpbGwgZml4IHRoZSBhYm92ZSBuaXRzIGluIG5leHQgcmV2 aXNpb24uDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IA0KPiAtLQ0KPiBDaHJpcyBJbmFjaW8N Cj4gaW5hY2lvQGNlcnQub3JnDQo+IA0KPiANCg0K From nobody Mon Jan 5 02:10:27 2015 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 68D491A1BEA; Sun, 4 Jan 2015 23:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ugcm3nk9Ykd; Sun, 4 Jan 2015 23:43:06 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FC61A1BE4; Sun, 4 Jan 2015 23:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3477; q=dns/txt; s=iport; t=1420443786; x=1421653386; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=D5Z8u2ELuVaBQ7rxx0qJcYv7l6fBwWrWGB2YtANWxSo=; b=cZFhcB675nL3MkHi7/t1p/PoZk/7lAFTBEeuVs1RShqqq9zdTSUxZaLX jKCoxIyMiNpQT6mAjuiWu9sGj/VHkZ0ljq4x9suyUO5YQyBL4xe/P3YhS UPsprFYg2vBBCPPW7hunHFXhNiZbaUgS1sgWYRlONOMPmV2oYWW5YXpYB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFAN4/qlStJV2U/2dsb2JhbABcgwaBKgTDdIgWAoEEFgEBAQEBfYQNAQEEgQkCAQg/BzIUEQIEARKILLtxAQEBAQEBAQMBAQEBAR2PRDqEKQEEjhWIc5FQIoNubwGBBCQcfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,698,1413244800"; d="scan'208";a="110311255" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 05 Jan 2015 07:43:05 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t057h45f007532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 07:43:04 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.100]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 01:43:04 -0600 From: "Prashanth Patil (praspati)" To: "mohamed.boucadair@orange.com" , "Chris Inacio" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-pcp-server-selection.all@tools.ietf.org" Thread-Topic: sector review of draft-ietf-pcp-server-selection-07 Thread-Index: AQHQKLs9yOlJryMOcUmiTJHGP8qETA== Date: Mon, 5 Jan 2015 07:43:04 +0000 Message-ID: References: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> <787AE7BB302AE849A7480A190F8B9330048DEF48@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330048DEF48@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.77.65] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9572754CD75780408E416E28AF6A3468@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/h6QkDQHwZS_CsRNbAKwdrT-sHJs X-Mailman-Approved-At: Mon, 05 Jan 2015 02:10:24 -0800 Subject: Re: [secdir] sector review of draft-ietf-pcp-server-selection-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: Mon, 05 Jan 2015 07:43:08 -0000 Hi Med, Given that this is a recommendation for efficiency, we could perhaps change 'SHOULD' to a 'MAY'. We only introduced this because it's easier on the client to use the same mapping nonce when it tries to connect with each address of the same server in a sequential manner. -Prashanth On 1/5/15 1:04 PM, "mohamed.boucadair@orange.com" wrote: >Dear Chris, > >Thank you for the review. > >Nonce validation checks are used when operating in the simple threat >model as discussed in RFC6887. Adding a reference to section 18.1 of >RFC6887 would be sufficient IMHO. PCP authentication will be needed if >operating in the Advanced Threat Model. > >OLD: >For efficiency, the PCP client SHOULD use the same Mapping Nonce for >requests sent to all IP addresses belonging to the same PCP server. > >NEW: > For efficiency, the PCP client SHOULD use the same Mapping Nonce for >requests sent to all IP addresses belonging to the same PCP server. As a >reminder, nonce validation checks are performed when operating in the >Simple Threat Model (Section 18.1 of [RFC6887]) to defend against some >off-path attacks.=20 > >Better? > >I already fixed the nits in my local copy. > >Thank you. > >Cheers, >Med > >-----Message d'origine----- >De : Chris Inacio [mailto:inacio@cert.org] >Envoy=E9 : dimanche 4 janvier 2015 07:57 >=C0 : secdir@ietf.org; iesg@ietf.org; >draft-ietf-pcp-server-selection.all@tools.ietf.org >Objet : sector review of draft-ietf-pcp-server-selection-07 > > > >I have reviewed this document as part of the security directorate=B9s >ongoing effort to review all IETF documents being processed by the IESG. >These comments were written with the intent of improving security >requirements and considerations in IETF drafts. Comments not addressed >in last call may be included in AD reviews during the IESG review. >Document editors and WG chairs should treat these comments just like any >other last call comments. > >Generally the document is in good shape, and I would like to see one >minor issue at least commented upon. > >I have a single security related comment on this draft; the last sentence >of section 3: > >> For efficiency, the PCP client SHOULD use the same Mapping Nonce for >> requests sent to all IP addresses belonging to the same PCP server. > >Normally, I would simply say this is a crazy recommendation. But after >looking a little into what the Nonce is used for in the PCP protocol, I >am slightly less distraught. This Nonce does not appear to necessarily >provide any huge amount of security except allowing the client to >generate a unique token per PCP server. Presumably there is a general >MITM attack on the PCP protocol related to the Nonce as a transaction ID >which is prevented by using other security protocols, TLS, etc. (And >another well known attack with the THIRD_PARTY option and lack of >authentication=8A) Therefore, this Nonce is critical as a synchronization >point between the client and the potential PCP server. It would be nice >(assuming all that is correct) to make that clear in the document, >especially with a recommendation to reuse the Nonce. > > >Nits: > >In Figure 1, the lines are not aligned to the =B3+=B2 on the diagrams. > >In Figure 3, =B3rtr1=B2 is missing a =B3+=B2 on the right side connection = from >the top. > > >-- >Chris Inacio >inacio@cert.org > > > From nobody Mon Jan 5 03:14:17 2015 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 4714C1A1B74; Mon, 5 Jan 2015 03:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oJmTpRMG0s0Y; Mon, 5 Jan 2015 03:14:14 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C131A0231; Mon, 5 Jan 2015 03:14:14 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 7D790DA06DE; Mon, 5 Jan 2015 11:14:14 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5DBFA53E087; Mon, 5 Jan 2015 03:14:14 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 5 Jan 2015 03:14:14 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 5 Jan 2015 06:13:53 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <966E0D3C-815F-4131-91B1-FF0EF7568DFD@nominum.com> References: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> <787AE7BB302AE849A7480A190F8B9330048DEF48@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: "Prashanth Patil (praspati)" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LIHbqgr8gD00Ujh_lWZ9ppWadXk Cc: "draft-ietf-pcp-server-selection.all@tools.ietf.org" , "mohamed.boucadair@orange.com" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-pcp-server-selection-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: Mon, 05 Jan 2015 11:14:16 -0000 On Jan 5, 2015, at 2:43 AM, Prashanth Patil (praspati) = wrote: > Given that this is a recommendation for efficiency, we could perhaps > change 'SHOULD' to a 'MAY'. This would require a new WGLC. I recommend against it: if the advice = is good, it is good, and should be followed. If it is not good, it = should be removed. The working group seemed to think it was good = advice, so why change that now? If you have a strong reason for = changing it, I would of course support that, but I haven't heard one = expressed. From nobody Mon Jan 5 03:48:26 2015 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 5FD5B1A3BA4; Mon, 5 Jan 2015 03:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBMsiDLfPnc1; Mon, 5 Jan 2015 03:48:19 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846301A3BA0; Mon, 5 Jan 2015 03:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=714; q=dns/txt; s=iport; t=1420458500; x=1421668100; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mZtAIbd8V8zu1pTquAYpOowSKd+eLDp7/bOEZEJxHLM=; b=krccidWhZ7kn9HOPimgklZOV4TW1IejqQOflyWWkUxhhPO2DMuBib5az 6LPjqlEclPuTT6BsxFti/v8/jOHURS/Pd1amo5L7chvqWiIETSLdCc3dp MeuFdCSY4hIlUx5pZWFQ2uowLIxyrNAcJyHgbkFwMzhGF8mPGCN4jx9UR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFAH95qlStJA2F/2dsb2JhbABcgwaBKgTDdogWAoEGFgEBAQEBfYQNAQEEeRACAQgYLjIlAgQOBYgsvHABAQEBAQEBAQEBAQEBAQEBAQEBGY93B4QpAQSJIYR0iHORUCKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,698,1413244800"; d="scan'208";a="110300508" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 05 Jan 2015 11:48:19 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t05BmHJw013223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 11:48:17 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.100]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 05:48:17 -0600 From: "Prashanth Patil (praspati)" To: Ted Lemon Thread-Topic: sector review of draft-ietf-pcp-server-selection-07 Thread-Index: AQHQKNiwAUxKUQpnyUK05uEkCW52tJyyKhAA Date: Mon, 5 Jan 2015 11:48:17 +0000 Message-ID: References: <0FD1DF78-8EEC-44F2-B715-9CD7405C07D6@cert.org> <787AE7BB302AE849A7480A190F8B9330048DEF48@OPEXCLILM23.corporate.adroot.infra.ftgroup> <966E0D3C-815F-4131-91B1-FF0EF7568DFD@nominum.com> In-Reply-To: <966E0D3C-815F-4131-91B1-FF0EF7568DFD@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.77.65] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <08FD59C941DC4847BF87B6A359D36F65@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PPEmh5xw1jNcohRtit37fFJMMwk Cc: "draft-ietf-pcp-server-selection.all@tools.ietf.org" , "mohamed.boucadair@orange.com" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-pcp-server-selection-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: Mon, 05 Jan 2015 11:48:21 -0000 Hi Ted, I don=B9t have a strong reason, we don=B9t need to change it. -Prashanth On 1/5/15 4:43 PM, "Ted Lemon" wrote: >On Jan 5, 2015, at 2:43 AM, Prashanth Patil (praspati) > wrote: >> Given that this is a recommendation for efficiency, we could perhaps >> change 'SHOULD' to a 'MAY'. > >This would require a new WGLC. I recommend against it: if the advice is >good, it is good, and should be followed. If it is not good, it should >be removed. The working group seemed to think it was good advice, so >why change that now? If you have a strong reason for changing it, I >would of course support that, but I haven't heard one expressed. > From nobody Mon Jan 5 06:49:51 2015 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 150F21A88B9; Mon, 5 Jan 2015 06:49:46 -0800 (PST) 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 OjUomhZPAQTo; Mon, 5 Jan 2015 06:49:43 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01451A88B2; Mon, 5 Jan 2015 06:49:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 664BAE2039; Mon, 5 Jan 2015 09:49:42 -0500 (EST) 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 15037-09; Mon, 5 Jan 2015 09:49:40 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (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 935A0E2035; Mon, 5 Jan 2015 09:49:40 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t05EnbfH026901; Mon, 5 Jan 2015 09:49:37 -0500 From: Derek Atkins To: Jan Pechanec References: Date: Mon, 05 Jan 2015 09:49:37 -0500 In-Reply-To: (Jan Pechanec's message of "Mon, 29 Dec 2014 21:53:37 -0800 (PST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (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/ZQPgF0QmuOYvOG3vzdCRyu-IOfI Cc: Darren.Moffat@oracle.com, secdir@ietf.org, iesg@ietf.org Subject: Re: [secdir] sec-dir review of draft-pechanec-pkcs11uri-16 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, 05 Jan 2015 14:49:46 -0000 Thanks. Your changes look good to me. Happy New Year. -derek Jan Pechanec writes: > On Fri, 26 Dec 2014, Derek Atkins wrote: > >>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 with the intent of improving >>security requirements and considerations in IETF drafts. Comments >>not addressed in last call may be included in AD reviews during the >>IESG review. Document editors and WG chairs should treat these >>comments just like any other last call comments. >> >>I believe this document has no issues. > > dear Derek, thank you for your time to review the document. > My comments are inline below. > >>Editorial comments: >> >>In section 1: >> >> A subset of existing PKCS#11 structure members and object attributes >> was chosen believed to be sufficient in uniquely identifying a >> PKCS#11 token, storage object, or library in a configuration file, on >> ... >> >>This sentence is not just long but also awkward. The phrase "was > > I agree. I've simplified that in the following way: > > A subset of existing PKCS#11 structure members and object attributes > was chosen to uniquely identify a PKCS#11 storage object, token, > slot, or library in a configuration file, on a command line, or in a > configuration property of something else. Should there be a need for > a more complex information exchange on PKCS#11 entities a different > means of data marshalling should be chosen accordingly. > >>chosen believed to be.." seems to be missing a conjunction and >>possibly a verb. Maybe this was meant to be two sentences that got >>smushed together? >> >> >>In section 3.3: >> >> PKCS#11 specification imposes various limitations on the value of >> attributes, be it a more restrictive character set for the "serial" >> ... >> >>I think you need to start this sentence with an article, i.e. "The >>PKCS#11 specification imposes..." > > I've fixed that, thank you. > >>(I'll note that I did not validate the ABNF). > > there was a bug there and the grammar in the latest working > version of a new draft 17 was verified by: > > http://tools.ietf.org/tools/bap/abnf.cgi > > I've also attached the latest working version of draft 17. > > best regards, Jan. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Mon Jan 5 10:09:23 2015 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 8C4D61A8724; Mon, 5 Jan 2015 10:08:56 -0800 (PST) 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 naOzIWEEmrE1; Mon, 5 Jan 2015 10:08:49 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8DB1A0371; Mon, 5 Jan 2015 10:08:49 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so20088024lbj.23; Mon, 05 Jan 2015 10:08:47 -0800 (PST) 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=9jAT1ocOnjXpWMsaCN8ACAXCTmsQy6Ev0ghCWFt5v6A=; b=r6rr/DAAsjQ3D9/Jvp1zEZQUrD3xaHPCwW22Spz9w4DiRJCe7vkMufxghFpdwOtHJn OSAnFbxIsgv28DOVi0b7Ztbplm/apMAUn3kbbrQMjj35F12cxAAZdNRBQhUOcNGV9WBO T1SpJJHvQL+J/O7sHoZoW240FP7aGB1zMn1SXYn6B0DbVy9j7v0D6YnGIYKXxLsjUaC2 vz+6ZRdIaa2BtKRTUQwvBZBXeJ+iJqC/1MjISFJxXyzuIGl80ql8pEeIItWlj/S0Yxnb FIvOd0UnXANbhpLNmMXrQ8YyDiWRvaZdcexafsm8fJ746GCPd5OeVUf6p4Lw+Y5wTR/7 cDBw== MIME-Version: 1.0 X-Received: by 10.112.185.101 with SMTP id fb5mr51380838lbc.12.1420481327340; Mon, 05 Jan 2015 10:08:47 -0800 (PST) Received: by 10.25.17.196 with HTTP; Mon, 5 Jan 2015 10:08:47 -0800 (PST) Date: Mon, 5 Jan 2015 13:08:47 -0500 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" , draft-nottingham-safe-hint.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c3c516ed2143050beb94aa Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/JVk5rGUHkat7-cOREHuFLV5aoVs Subject: [secdir] SECDIR Review of Draft-nottingham-safe-hint 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, 05 Jan 2015 18:08:56 -0000 --001a11c3c516ed2143050beb94aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate=E2=80=99s= ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Some websites have both a standard version and also a "safe" version with "objectionable" content removed. This document specifies a mechanism for an HTTP client to request that -- in such a case -- the server provide the "safe" version. This document makes no attempt to define a "safe" website or to define "objectionable" content. It merely provides a way for the client to let the server know that a "safer" version is desired if multiple versions are available. This document is generally in good shape and I believe it is ready for publication. This mechanism is not intended to provide any security properties and the authors are clear in the security considerations with regards to security properties that are out of scope for this mechanism. However, the authors should consider making the following explicit in the security considerations section. In the case where an intermediary/man-in-the-middle changes the Prefer header (perhaps maliciously), it is not possible for the intermediary to produce a worse experience than would exist without this mechanism. That is, the mechanism only provides a way to request a safer-than-usual version of the website, therefore if the Prefer header is modified the worst that can happen is that the user is provided the "usual" version of the site -- the version that they would receive today without this mechanism. --001a11c3c516ed2143050beb94aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have review= ed this document as part of the security directorate=E2=80=99s ongoing effo= rt to review all IETF documents being processed by the IESG.=C2=A0 These co= mments were written with the intent of improving security requirements and = considerations in IETF drafts.=C2=A0 Comments not addressed in last call ma= y be included in AD reviews during the IESG review.=C2=A0 Document editors = and WG chairs should treat these comments just like any other last call com= ments.

Some websites have both a standard version and also a "s= afe" version with "objectionable" content removed. This docu= ment specifies a mechanism for an HTTP client to request that -- in such a = case -- the server provide the "safe" version. This document make= s no attempt to define a "safe" website or to define "object= ionable" content. It merely provides a way for the client to let the s= erver know that a "safer" version is desired if multiple versions= are available.

This document is generally in good shape and I belie= ve it is ready for publication.

This mechanism is= not intended to provide any security properties and the authors are clear = in the security considerations with regards to security properties that are= out of scope for this mechanism.=C2=A0

However, t= he authors should consider making the following explicit in the security co= nsiderations section. In the case where an intermediary/man-in-the-middle c= hanges the Prefer header (perhaps maliciously), it is not possible for the = intermediary to produce a worse experience than would exist without this me= chanism. That is, the mechanism only provides a way to request a safer-than= -usual version of the website, therefore if the Prefer header is modified t= he worst that can happen is that the user is provided the "usual"= version of the site -- the version that they would receive today without t= his mechanism.
--001a11c3c516ed2143050beb94aa-- From nobody Mon Jan 5 10:09:25 2015 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 04D961A0371 for ; Mon, 5 Jan 2015 10:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 aKcIMu-abxX3 for ; Mon, 5 Jan 2015 10:08:50 -0800 (PST) Received: from smtp106.ord1c.emailsrvr.com (smtp106.ord1c.emailsrvr.com [108.166.43.106]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD2F1A8725 for ; Mon, 5 Jan 2015 10:08:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp22.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 864831804E5; Mon, 5 Jan 2015 13:08:49 -0500 (EST) X-Virus-Scanned: OK Received: by smtp22.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D64FB180181; Mon, 5 Jan 2015 13:08:48 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 05 Jan 2015 18:08:49 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Olafur Gudmundsson In-Reply-To: Date: Mon, 5 Jan 2015 13:08:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> To: Randy Bush X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/eNKJozs-d_KDLhYe2-ngFB73cU4 Cc: draft-ietf-ospf-te-metric-extension@tools.ietf.org, ietf , secdir@ietf.org Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 18:09:00 -0000 > On Jan 3, 2015, at 7:48 PM, Randy Bush wrote: >=20 >> The document contains no issues from a security perspective as it is >> only creating LSA=E2=80=99s for new types of route selection metrics, = time >> instead of network hops. >=20 > and the new lsas could not be used in path shortening attacks, right? >=20 > randy >=20 Randy, this document only defines the format of the LSA=E2=80=99s it does not talk about processing by the routing engines.=20 Olafur From nobody Mon Jan 5 11:07:37 2015 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 7CAB61A879C; Mon, 5 Jan 2015 10:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uNmeIKp-3BlI; Mon, 5 Jan 2015 10:43:33 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F8D1A87A8; Mon, 5 Jan 2015 10:43:21 -0800 (PST) Received: from BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) by BLUPR05MB056.namprd05.prod.outlook.com (10.255.210.151) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 18:42:58 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 18:42:58 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 18:42:58 +0000 From: John E Drake To: Olafur Gudmundsson , ietf Thread-Topic: Sector Review: draft-ietf-ospf-te-metric-extensions-09 Thread-Index: AQHQJ3SMyWjtcXq4JUqwQi9EiIdlY5yx3hXw Date: Mon, 5 Jan 2015 18:42:57 +0000 Message-ID: References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> In-Reply-To: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:BLUPR05MB564; UriScan:; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(19300405004)(31966008)(101416001)(62966003)(19625215002)(76576001)(87936001)(4396001)(16236675004)(102836002)(77096005)(2656002)(68736005)(15975445007)(2900100001)(2950100001)(54356999)(77156002)(76176999)(92566001)(86362001)(21056001)(40100003)(105586002)(50986999)(97736003)(33656002)(106116001)(106356001)(107046002)(99396003)(230783001)(122556002)(99286002)(120916001)(46102003)(19580395003)(74316001)(19580405001)(20776003)(64706001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BLUPR05MB56263FED888E98674F8974DC7580BLUPR05MB562namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2015 18:42:57.9072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB564 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB056; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TLAa5jMWdCRFXyDkyvBFT01BuyU X-Mailman-Approved-At: Mon, 05 Jan 2015 11:07:31 -0800 Cc: "secdir@ietf.org" Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 18:43:36 -0000 --_000_BLUPR05MB56263FED888E98674F8974DC7580BLUPR05MB562namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2xhZnVyLA0KDQpMaW5rIGRlbGF5IGlzIHByb3BhZ2F0aW9uIGRlbGF5IGFuZCAxIG1pY3Jvc2Vj b25kIGNvcnJlc3BvbmRzIHRvIGEgbGluayB3aXRoIGEgbGVuZ3RoIG9mIC4zIEtNLg0KDQpZb3Vy cyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQpGcm9tOiBpZXRmIFttYWlsdG86aWV0Zi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xhZnVyIEd1ZG11bmRzc29uDQpTZW50OiBTYXR1 cmRheSwgSmFudWFyeSAwMywgMjAxNSAxMTo0NCBBTQ0KVG86IGlldGYNCkNjOiBzZWNkaXJAaWV0 Zi5vcmcNClN1YmplY3Q6IFNlY3RvciBSZXZpZXc6IGRyYWZ0LWlldGYtb3NwZi10ZS1tZXRyaWMt ZXh0ZW5zaW9ucy0wOQ0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9m IHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCklFU0cuICBUaGVzZSBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCnNlY3Vy aXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3Vs ZCB0cmVhdA0KdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29t bWVudHMuDQoNCg0KVGhpcyBkb2N1bWVudCBpcyBSZWFkeSB3aXRoIG5pdHMuDQoNClRoZSBkb2N1 bWVudCBjb250YWlucyBubyBpc3N1ZXMgZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlIGFzIGl0 IGlzIG9ubHkgY3JlYXRpbmcgTFNB4oCZcyBmb3IgbmV3IHR5cGVzIG9mIHJvdXRlIHNlbGVjdGlv biBtZXRyaWNzLA0KdGltZSBpbnN0ZWFkIG9mIG5ldHdvcmsgaG9wcy4NCg0KVGhlIE5pdCB0aGF0 IEkgaGF2ZSBpcyB0aGUgZG9jdW1lbnQgaW4gaW50cm9kdWN0aW9uIHNheXMgdGltZSBpcyBpbXBv cnRhbnQgYW5kIHRoZSBhYmlsaXR5IHRvIHNlbGVjdCBmYXN0ZXIgcGF0aCBoYXMgaGlnaA0KZWNv bm9taWNhbCBnYWluLg0KVGhlIGJhc2UgdGltZSBtZWFzdXJlbWVudCB1bml0IGluIHRoZSBuZXcg TFNB4oCZcyBpcyBNSUNSTyBzZWNvbmRzLCB0aGVyZSBpcyBubyBqdXN0aWZpY2F0aW9uIGluIHRo ZSBkb2N1bWVudCB0aGF0DQpzYXlzIDEgbWljcm8gc2Vjb25kIGlzIGdyYW51bGFyIGVub3VnaCBm b3IgbGlua3Mgb2YgdGhlIG5lYXIgZnV0dXJlIChvdmVyIDEwMCBHYml0cyspLg0KDQpPbGFmdXIN Cg0K --_000_BLUPR05MB56263FED888E98674F8974DC7580BLUPR05MB562namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sbzsNCglwYW5vc2UtMTowIDAgMCAw IDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T2xhZnVyLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGluayBkZWxheSBpcyBwcm9wYWdhdGlvbiBkZWxh eSBhbmQgMSBtaWNyb3NlY29uZCBjb3JyZXNwb25kcyB0byBhIGxpbmsgd2l0aCBhIGxlbmd0aCBv ZiAuMyBLTS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPllvdXJzIElycmVzcGVjdGl2ZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gaWV0ZiBbbWFpbHRvOmlldGYtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+T2xhZnVyIEd1ZG11bmRzc29uPGJy Pg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51YXJ5IDAzLCAyMDE1IDExOjQ0IEFNPGJyPg0K PGI+VG86PC9iPiBpZXRmPGJyPg0KPGI+Q2M6PC9iPiBzZWNkaXJAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gU2VjdG9yIFJldmlldzogZHJhZnQtaWV0Zi1vc3BmLXRlLW1ldHJpYy1leHRl bnNpb25zLTA5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+ SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNZW5sbyZx dW90OyxzZXJpZiI+b25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O01lbmxvJnF1b3Q7LHNlcmlmIj5JRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2VyaWYiPnNlY3VyaXR5IGFyZWEgZGly ZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlm Ij50aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNl cmlmIj5UaGlzIGRvY3VtZW50IGlzIFJlYWR5IHdpdGggbml0cy4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+VGhlIGRvY3VtZW50IGNv bnRhaW5zIG5vIGlzc3VlcyBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUgYXMgaXQgaXMgb25s eSBjcmVhdGluZyBMU0HigJlzIGZvciBuZXcgdHlwZXMgb2Ygcm91dGUgc2VsZWN0aW9uIG1ldHJp Y3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlmIj50 aW1lIGluc3RlYWQgb2YgbmV0d29yayBob3BzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlmIj5UaGUgTml0IHRoYXQgSSBoYXZlIGlzIHRo ZSBkb2N1bWVudCBpbiBpbnRyb2R1Y3Rpb24gc2F5cyB0aW1lIGlzIGltcG9ydGFudCBhbmQgdGhl IGFiaWxpdHkgdG8gc2VsZWN0IGZhc3RlciBwYXRoIGhhcyBoaWdoPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlmIj5lY29ub21pY2FsIGdhaW4uJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlmIj5UaGUg YmFzZSB0aW1lIG1lYXN1cmVtZW50IHVuaXQgaW4gdGhlIG5ldyBMU0HigJlzIGlzIE1JQ1JPIHNl Y29uZHMsIHRoZXJlIGlzIG5vIGp1c3RpZmljYXRpb24gaW4gdGhlIGRvY3VtZW50IHRoYXQmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2VyaWYiPnNh eXMgMSBtaWNybyBzZWNvbmQgaXMgZ3JhbnVsYXIgZW5vdWdoIGZvciBsaW5rcyBvZiB0aGUgbmVh ciBmdXR1cmUgKG92ZXIgMTAwIEdiaXRzJiM0MzspLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNlcmlmIj5PbGFmdXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR05MB56263FED888E98674F8974DC7580BLUPR05MB562namprd_-- From nobody Mon Jan 5 13:07:17 2015 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 B53E71A8A69; Mon, 5 Jan 2015 13:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 GPTB-W3g7rOK; Mon, 5 Jan 2015 13:06:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D221A8A67; Mon, 5 Jan 2015 13:06:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y8ErU-00063C-Ok; Mon, 05 Jan 2015 21:06:53 +0000 Date: Tue, 06 Jan 2015 06:06:51 +0900 Message-ID: From: Randy Bush To: Olafur Gudmundsson In-Reply-To: <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GaQnLl06Py8pFaHwTjbKjmNJZV4 Cc: draft-ietf-ospf-te-metric-extension@tools.ietf.org, ietf , secdir@ietf.org Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 21:07:12 -0000 >>> The document contains no issues from a security perspective as it is >>> only creating LSA=E2=80=99s for new types of route selection metrics, t= ime >>> instead of network hops. >>=20 >> and the new lsas could not be used in path shortening attacks, right? > > this document only defines the format of the LSA=E2=80=99s it does > not talk about processing by the routing engines.=20 so the secdir sees no need to warn about it. got it. randy From nobody Mon Jan 5 13:18:22 2015 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 9EE1B1A8A8C for ; Mon, 5 Jan 2015 13:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3s4CKer3SpDU for ; Mon, 5 Jan 2015 13:18:20 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7791A8A8B for ; Mon, 5 Jan 2015 13:18:19 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id j5so4779016qga.7 for ; Mon, 05 Jan 2015 13:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yYpsNEQMil/t2xizsOadYMNt6nXV1LrPOeI47+pEnXQ=; b=SvVKw7cvbnR88mMRnjGzkFOHWfK+yakaqfIdD80Rc0+eAG1VFymUXCChUsKRwQHg7B bScUk08OTH/3s3KvcFk919Zu5PQkZJqSatg0AiId0A4ybI+63yHZM1gOtfXotTKqC3PX SN+C7z1TtroS+Q2z9uZpqbh3QFf6Z81ISOs2eR79YBoRc+BjplGnI2w2WzgmPt+witJz i9nqrCFAmXZQ93R405I2ixUJCiK4Ys7WR3a+6HUlLFgABFkh4lZ0KD22Au3anIkL7aYi q8PWGqL8p11CA7KWMppqajd4JsPqBi96TnI3oTUW38O4PRkeRb34McEOz1AnFIGmCkKX 7EIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yYpsNEQMil/t2xizsOadYMNt6nXV1LrPOeI47+pEnXQ=; b=SRJFFPWTdkZpILL3KauRp2RlFDPDbKisag4TUxelDeijLYUTeQP7Ex2WvlLxMArxCE pMdEv1wWmTw52N65qK0HaZR1/xpW+4MUhcR8jd/HJhLGuAwXcpM1zlnml3xL2hrGmLOw 4p/xjv2mg6dMT2E/81Gq8skwA1j4tSpgXc8mFhd2CBMMxfFmEm4ZTzEw7A50cIEq44py 5HJ0czILWwod4qXZpi+4tiprwKkKTYbHL1/4O8T2ySNkujNXShSec6ifOUpCtRSO6dNP PtLWD+L1Rf7uwHIyoi/kyZzoVxLLOx+hWHXLog8JuG/DwcNEM0+76BC4ThFyQFKsDm5A ew8Q== X-Gm-Message-State: ALoCoQnI/S5aQB4RhX0bxBAAdJJpZMZwEzano4ni/rb02x/aqDjQY1HKmTA7SLvr/mvNzixiJBlL MIME-Version: 1.0 X-Received: by 10.224.137.65 with SMTP id v1mr138862790qat.95.1420492699058; Mon, 05 Jan 2015 13:18:19 -0800 (PST) Received: by 10.229.183.201 with HTTP; Mon, 5 Jan 2015 13:18:18 -0800 (PST) In-Reply-To: References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> Date: Mon, 5 Jan 2015 21:18:18 +0000 Message-ID: From: Ben Laurie To: Randy Bush Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8KMfaCy9YGZ7xvi2IA2MX-fRmSQ Cc: draft-ietf-ospf-te-metric-extension@tools.ietf.org, ietf , "secdir@ietf.org" Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 21:18:21 -0000 On 5 January 2015 at 21:06, Randy Bush wrote: >>>> The document contains no issues from a security perspective as it is >>>> only creating LSA=E2=80=99s for new types of route selection metrics, = time >>>> instead of network hops. >>> >>> and the new lsas could not be used in path shortening attacks, right? >> >> this document only defines the format of the LSA=E2=80=99s it does >> not talk about processing by the routing engines. > > so the secdir sees no need to warn about it. got it. If secdir is going to warn about it through this process, then shortly the right place to do that is in the comments on the document that does talk about processing by the routing engines? From nobody Mon Jan 5 13:18:46 2015 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 DE1721A8A90 for ; Mon, 5 Jan 2015 13:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NC26tXAdoA0c for ; Mon, 5 Jan 2015 13:18:43 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CDB1A8A82 for ; Mon, 5 Jan 2015 13:18:43 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so16280545qcz.10 for ; Mon, 05 Jan 2015 13:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vqXf3/7DLU9RAOyir0v5ZcLCm1/qdLXKT7FlAh6NFYM=; b=WmGjyIeNEc+uVq+lmLBDvHy5tFkIhRU/gNla0P2d9s4T6Nq5m2R9XqCmAIqtFSUYwV ruk2Ijgnt2NATLeBBv0U2z4mxDEjr8J8sALscqc/0Ldik68eCxgrAXP62dSYqvNd1r6h uBqddI9GiWwKRC4OqhQZ+tP9bAqLYWqu0ubtuVQ2egQWk3jYxOjsk5yeT6N5fvPpO8ia LeOX2xGf3ZrGl1nhEF5zBT3Sj6+CUsBgzsPv2GkkxG95HNOrgjv91DC7+CBt0JurzluQ P/T3wZXUFi2qbyCHWH+l43QgH6KZfuJkwWWMDWCGcUOs9PPQLHHv3nooMUbddaocqk49 U3Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vqXf3/7DLU9RAOyir0v5ZcLCm1/qdLXKT7FlAh6NFYM=; b=VpQnahSs38foyyA2F1DVxNtsdkdJ54yZcJe/Bz8PZE9MWs+5+MBtIht+5p2XTVd842 kWDAtlQYeeYnTUaLhala76dZxvDBGlNHMCkVtv4TaJz86pLa78tBGQtTWTmu3f6KovyX SBUJPe1pCQpMcZSy2K0DBnzlz7E1Wd4La55GPDH8nI2xYYCVz5f737RFycWe4/qbxC2A l6CoFxZb7s+gA2bSWi3k95uOQtsoK3E6WSbkLI4YoGNv7EtFlPXI+t/7bqFYp0ryQ8ZW jkMevh/oiI3TUYqhLuBV7kEilq9i7vLC9RXtuWaqwWYcM/EVbR1XvP8hxv1VUMJmT+Tm PL/Q== X-Gm-Message-State: ALoCoQntfv9lYPkojp36ASOFqD06ctVo4pksAi/C9tzG535tvCoytCXYLkkC9CD966Dmvptd60Tl MIME-Version: 1.0 X-Received: by 10.229.93.132 with SMTP id v4mr148083065qcm.27.1420492722663; Mon, 05 Jan 2015 13:18:42 -0800 (PST) Received: by 10.229.183.201 with HTTP; Mon, 5 Jan 2015 13:18:42 -0800 (PST) In-Reply-To: References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> Date: Mon, 5 Jan 2015 21:18:42 +0000 Message-ID: From: Ben Laurie To: Randy Bush Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/DDXOMKUtzsmokbwP_kacKuYv1FI Cc: draft-ietf-ospf-te-metric-extension@tools.ietf.org, ietf , "secdir@ietf.org" Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 21:18:45 -0000 On 5 January 2015 at 21:18, Ben Laurie wrote: > On 5 January 2015 at 21:06, Randy Bush wrote: >>>>> The document contains no issues from a security perspective as it is >>>>> only creating LSA=E2=80=99s for new types of route selection metrics,= time >>>>> instead of network hops. >>>> >>>> and the new lsas could not be used in path shortening attacks, right? >>> >>> this document only defines the format of the LSA=E2=80=99s it does >>> not talk about processing by the routing engines. >> >> so the secdir sees no need to warn about it. got it. > > If secdir is going to warn about it through this process, then shortly Good grief. Surely. > the right place to do that is in the comments on the document that > does talk about processing by the routing engines? From nobody Mon Jan 5 13:33:16 2015 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 744FE1A8AA2; Mon, 5 Jan 2015 13:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 H2NiSOpW4dH5; Mon, 5 Jan 2015 13:33:10 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A4D1A007C; Mon, 5 Jan 2015 13:33:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y8FGu-0006DA-0c; Mon, 05 Jan 2015 21:33:08 +0000 Date: Tue, 06 Jan 2015 06:33:05 +0900 Message-ID: From: Randy Bush To: Ben Laurie In-Reply-To: References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/a1RNMsU71_tdT2JAg92-XEiEgdc Cc: ietf , secdir Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 21:33:12 -0000 >>>> and the new lsas could not be used in path shortening attacks, >>>> right? >>> >>> this document only defines the format of the LSA=E2=80=99s it does not = talk >>> about processing by the routing engines. >> >> so the secdir sees no need to warn about it. got it. >=20 > If secdir is going to warn about it through this process, then surely > the right place to do that is in the comments on the document that > does talk about processing by the routing engines? a na=C3=AFve person might think that all documents in a series that have security implications would be flagged in the security considerations section. but i have had my say. let's get back to work. randy From nobody Mon Jan 5 13:41:22 2015 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 A86F11A8ACE for ; Mon, 5 Jan 2015 13:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4kP05r2lmFy9 for ; Mon, 5 Jan 2015 13:41:18 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD541A8AB4 for ; Mon, 5 Jan 2015 13:41:18 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i13so13232003qae.38 for ; Mon, 05 Jan 2015 13:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Rsow4jK3dFo7MwtpUnfHA36AEfkUq0szgLwwDNiNJg0=; b=hwwaM6Xr1gnoLGa3up/fjJTlW34G8GZ+55FxYgQeXPSY5xxTLqSwKLYA7XCWrrJ/JS Xk2qrl3qlzT1EEWS2IZFSpH9vfauD14XIX60VwOX8Vwr/vD5cf02QC7pdhysUYPGYJ9b Nnuox4nG9OUZ6PuO+Yd8+fqGFp3Z7YunPfZboFtcIBFAng+jiQ5ggAcDKWlsBic3mgg2 EkEdLl+uc7mzQK2WQtzHo/tqrr/yqAhoc2xXtsbbv19W8aLNHPNNWjBOQMnjk/DxEsKn DwuiwcoaOM3pl/MjxhBCr23QsyqDYuJFz1LWjoXHxiHw94H7RzEWjnGgGo6OMpN1Hspp 8F1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rsow4jK3dFo7MwtpUnfHA36AEfkUq0szgLwwDNiNJg0=; b=Cc1tmKF34jxK1sn7jhDN6UUT0GcQPtGvn9c5neaKACOVVPUi00ggTREaE9f10rY3MH bfsm/wSFmghn5TTSMQGsDAeI6LaDvY65Cs0ptUiHD8CMG8Bu3UV4zSMcqMP3l0oGc/AV SAi/2P4CLnk06uOFRYfjtKzbDhJNp/L0PmbSueboZs4qxoi4Xmo5uT7M3+O2YLrF8wsy GrEVVX3cgd2Cz96h/L10Lj6NdkNcghjcME1AHsp6cbPNpxBaPNR4lCbyy4EX1SCOn18o a8m+Ir1HbBpjmqKsbhW05AoNIJ8JHajpGuTezqqAoT6hvOI7D6zSrhJKqtCOmG0tlUPL TnWQ== X-Gm-Message-State: ALoCoQm2DzOCbMAVs28BpNaYgVwdCsePZ/+BUev0L/29hDmESepyHxd6+dlCXd2poo0rTGA91EMr MIME-Version: 1.0 X-Received: by 10.140.36.239 with SMTP id p102mr142369222qgp.8.1420494077462; Mon, 05 Jan 2015 13:41:17 -0800 (PST) Received: by 10.229.183.201 with HTTP; Mon, 5 Jan 2015 13:41:17 -0800 (PST) In-Reply-To: References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> Date: Mon, 5 Jan 2015 21:41:17 +0000 Message-ID: From: Ben Laurie To: Randy Bush Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jrcIsACewchHjYn-CZD63D61LwM Cc: ietf , secdir Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 21:41:19 -0000 On 5 January 2015 at 21:33, Randy Bush wrote: >>>>> and the new lsas could not be used in path shortening attacks, >>>>> right? >>>> >>>> this document only defines the format of the LSA=E2=80=99s it does not= talk >>>> about processing by the routing engines. >>> >>> so the secdir sees no need to warn about it. got it. >> >> If secdir is going to warn about it through this process, then surely >> the right place to do that is in the comments on the document that >> does talk about processing by the routing engines? > > a na=C3=AFve person might think that all documents in a series that have > security implications would be flagged in the security considerations > section. Seriously? What about the implications of other sections? Should they also be flagged? Or would a naive person perhaps think that to understand a series, you should read all of it? From nobody Mon Jan 5 13:47:57 2015 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 4DF941A8ADD; Mon, 5 Jan 2015 13:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 O7j9kTSQc16d; Mon, 5 Jan 2015 13:47:52 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C446B1A0049; Mon, 5 Jan 2015 13:47:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 362DEBEC0; Mon, 5 Jan 2015 21:47:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvo3RhdPOHXY; Mon, 5 Jan 2015 21:47:50 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D48C2BEBC; Mon, 5 Jan 2015 21:47:49 +0000 (GMT) Message-ID: <54AB0685.7080602@cs.tcd.ie> Date: Mon, 05 Jan 2015 21:47:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Randy Bush , Ben Laurie References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8dI5e1jN7VQgx0itZqMroGgZy2Q Cc: ietf , secdir Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 21:47:55 -0000 On 05/01/15 21:33, Randy Bush wrote: >>>>> and the new lsas could not be used in path shortening attacks, >>>>> right? >>>> >>>> this document only defines the format of the LSA’s it does not talk >>>> about processing by the routing engines. >>> >>> so the secdir sees no need to warn about it. got it. >> >> If secdir is going to warn about it through this process, then surely >> the right place to do that is in the comments on the document that >> does talk about processing by the routing engines? > > a naïve person might think that all documents in a series that have > security implications would be flagged in the security considerations > section. > > but i have had my say. let's get back to work. Yeah, I don't think arguing about it between secdir reviewers will help us so much:-) I noted that this had been raised in my ballot ([1] at the end) and asked if text is needed. Randy - if you have suggested text that could go in there that'd be good. I'm not clear enough about the relationship between that attack and this draft to know what'd be good to be honest. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ballot/#stephen-farrell > > randy > > > From nobody Mon Jan 5 14:10:07 2015 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 315A01A9007 for ; Mon, 5 Jan 2015 14:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 BYYRB82h4Xns for ; Mon, 5 Jan 2015 14:10:04 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC4B1A9005 for ; Mon, 5 Jan 2015 14:10:04 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y8Fqa-0006QY-7t; Mon, 05 Jan 2015 22:10:00 +0000 Date: Tue, 06 Jan 2015 07:09:58 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <54AB0685.7080602@cs.tcd.ie> References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> <54AB0685.7080602@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LzfEn42tzjXjUsd2qlphhn27Nqs Cc: secdir Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 22:10:06 -0000 [ off list as i am over my personal quota for the list ] >> but i have had my say. let's get back to work. > Yeah, I don't think arguing about it between secdir reviewers will > help us so much:-) i am not a secdir reviewer, and do not play one on tv > if you have suggested text that could go in there that'd be good. users of the lsas described in this document should be aware of how they might be used in path shortening and other routing attacks. but i am sure we can make it more complicated :) randy From nobody Mon Jan 5 14:23:14 2015 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 80AE41A8FD6 for ; Mon, 5 Jan 2015 14:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 M7QrJ1bpVwoW for ; Mon, 5 Jan 2015 14:23:12 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CF71A00E6 for ; Mon, 5 Jan 2015 14:23:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9FE20BEC0; Mon, 5 Jan 2015 22:23:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oodla9qc9H2; Mon, 5 Jan 2015 22:23:09 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 50D38BE88; Mon, 5 Jan 2015 22:23:09 +0000 (GMT) Message-ID: <54AB0ECD.308@cs.tcd.ie> Date: Mon, 05 Jan 2015 22:23:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Randy Bush References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> <54AB0685.7080602@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gKmVDfyDpJnd3PqgomvZHbaKrq8 Cc: secdir Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 22:23:13 -0000 On 05/01/15 22:09, Randy Bush wrote: > [ off list as i am over my personal quota for the list ] > >>> but i have had my say. let's get back to work. >> Yeah, I don't think arguing about it between secdir reviewers will >> help us so much:-) > > i am not a secdir reviewer, and do not play one on tv yep, a brain-fart of mine (maybe we'll try rope you in though:-) > >> if you have suggested text that could go in there that'd be good. > > users of the lsas described in this document should be aware of how > they might be used in path shortening and other routing attacks. > > but i am sure we can make it more complicated :) I added that suggestion to [1] (at end) S. [1] https://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ballot/ > > randy > > From nobody Mon Jan 5 14:45:22 2015 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 CA00A1A9069 for ; Mon, 5 Jan 2015 14:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ZLgBLf998WNz for ; Mon, 5 Jan 2015 14:45:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5F81A0108 for ; Mon, 5 Jan 2015 14:45:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y8GOh-0006bq-Hd; Mon, 05 Jan 2015 22:45:15 +0000 Date: Tue, 06 Jan 2015 07:45:14 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <54AB0ECD.308@cs.tcd.ie> References: <4E0F5009-4811-4FFE-AA26-ECFAC2398101@ogud.com> <96B524C4-B2E8-443E-871D-60B5FCD2F44A@ogud.com> <54AB0685.7080602@cs.tcd.ie> <54AB0ECD.308@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jJKhPBtU_8BqdGh4Kmh0Qr5Z9MY Cc: secdir Subject: Re: [secdir] Sector Review: draft-ietf-ospf-te-metric-extensions-09 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, 05 Jan 2015 22:45:21 -0000 >> i am not a secdir reviewer, and do not play one on tv > yep, a brain-fart of mine (maybe we'll try rope you in though:-) ENOTIME From nobody Tue Jan 6 14:22:00 2015 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 71CED1A8716 for ; Tue, 6 Jan 2015 14:18:50 -0800 (PST) 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 qo3D0s4CmNyD for ; Tue, 6 Jan 2015 14:18:47 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA2B1A0103 for ; Tue, 6 Jan 2015 14:18:47 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id c41so80604yho.27 for ; Tue, 06 Jan 2015 14:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DjAID+/XVg7dZnOA6dfY/pqpiOMrKcXEo/xAiprkFmI=; b=ou+j+gVJ3Ryq2EQmUwlGJWXxSB96FQGYn0x6NF/fetny1oh5vYVEMrZbuSyp43EoGD oCLyqGXmZOS4XwDFWilj+KnsYjAV+UfIMTg71GRd7ijjO6Kcs0dLVAHkx1mnEJ0R9uqG vNqn3B8QbNAuJXUYp8hSJzhJsF/hDEuXRpKBjvd9lcaTyO3mX/DnpfUbj+l/GqOXc7Az jvK6lC20kpVbT/qeImLcj6XIw7xpJ3s/Zkih2kIouM5DgJIUJMFbXOrwx9UnSS/STAO4 yppRpcoOJ7qk2zCWG3WRT6YnXMlZ0wKI0zKz/jr6fykqebo9uEJTWBV9fUU8ZTDyfbuB sjuA== MIME-Version: 1.0 X-Received: by 10.236.15.103 with SMTP id e67mr31289243yhe.3.1420582726269; Tue, 06 Jan 2015 14:18:46 -0800 (PST) Received: by 10.170.133.18 with HTTP; Tue, 6 Jan 2015 14:18:46 -0800 (PST) In-Reply-To: <5492F9F7.1070909@bbn.com> References: <074b01d00f31$1712da30$45388e90$@ndzh.com> <21650.47330.158595.209025@fireball.kivinen.iki.fi> <00e601d01ac4$b5b69b60$2123d220$@ndzh.com> <5492F9F7.1070909@bbn.com> Date: Tue, 6 Jan 2015 17:18:46 -0500 Message-ID: From: Alia Atlas To: Stephen Kent Content-Type: multipart/alternative; boundary=089e0122a476c61e05050c033016 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2rRHX_UZkF2CsxoyBLnGqR_leG8 X-Mailman-Approved-At: Tue, 06 Jan 2015 14:21:58 -0800 Cc: "Thomas D. Nadeau" , secdir , Kathleen Moriarty , "wardd@cisco.com" , Jeffrey Haas , Adrian Farrel , Susan Hares Subject: Re: [secdir] Security directorate 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, 06 Jan 2015 22:18:50 -0000 --089e0122a476c61e05050c033016 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks very much for doing this review. On Thu, Dec 18, 2014 at 10:59 AM, Stephen Kent wrote: > SECDIR early review of draft-ietf-i2rs-problem-statement-04 > > > > > > 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 with the intent of improving security requirements > and considerations in IETF drafts. Comments not addressed in last call > may be included in AD reviews during the IESG review. Document editors > and WG chairs should treat these comments just like any other last call > comments. > > > > This is a short document describing the problem being addressed by the > I2RS WG, and establishing some requirements for solutions. > > > > Section 2 describes the model for I2RS. It calls for using existing > transport protocols to provide security, a good statement as part of the > base protocol requirements. Looking at Figure 1, it seems that the only > paths that are in scope for I2RS are between an I2RS agent and client and > between clients. > > In section 5, authentication, authorization, and integrity are explicitly > cited as requirements. This is a good statement of requirements. It might > be nice to state whether confidentiality is also perceived as a > requirement, or if it explicitly not a requirement. > The sad answer is that it depends on what data is being sent. For instance, I can see counters or events not requiring confidentiality (depending) but some things being written or responses might require confidentiality. I've added in " Some communications will also require confidentiality." at the end of the Secure Control bullet. The Security Considerations section is a single paragraph consisting of 2 > sentences. It opens with a nice statement about the importance of securit= y > in the I2RS context. I think a back pointer to the =E2=80=9Csecure Contro= l=E2=80=9D text > would be appropriate. The second sentence says that more investigation is > needed to fully define security requirements such as authorization and > authentication levels. I don=E2=80=99t know what this last phrase means. > Authorization (aka access control) isn=E2=80=99t usually described as hav= ing levels > per se. Do you mean granularity of access control, or something else. Als= o, > for authentication, there are various mechanisms one can employ, and thes= e > may be described as offering varying =E2=80=9Clevels=E2=80=9D of security= , but that is an > oversimplification in many cases. A clearer description of what the autho= rs > are trying to convey here would be good. > I've updated the Security Considerations section to: "Security is a key aspect of any protocol that allows state installation and extracting of detailed router state. The need for secure control is mentioned in Section 5. More architectural security considerations are discussed in . Briefly, the I2RS Agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and the permissions associated with an I2RS Client. Mutual authentication between the I2RS Agent and I2RS Client is required. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS." I also looked briefly at draft-hares-i2rs-security-02. That document begins > with a very good discussion of security terminology based on RFC 4949. It > also proposes very specific security requirements for communications in t= he > I2RS model. That document calls for confidentiality as a requirement, whi= ch > further motivates some mention of this security service in the problem > statement, even if the statement is equivocal. > > > > > Two typos I noted: > > > > Section 2: measuresments -> measurements > > > > Section 5: > > > > Such communications must also have its integrity protected. -> > > > > Such communications must also be integrity-protected. > fixed Thanks again, Alia --089e0122a476c61e05050c033016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks very much for doing = this review.

O= n Thu, Dec 18, 2014 at 10:59 AM, Stephen Kent <kent@bbn.com> wrot= e:
=20 =20 =20
=20

SECDIR early review of draft-ietf-i2rs-problem-statement-04=

=C2= =A0

=C2= =A0

I have 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 with the intent of improving security requirements and considerations in IETF drafts. =C2=A0= Comments not addressed in last call may be included in AD reviews during the IESG review.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.

=C2= =A0

This is a short document describing the problem being addressed by the I2RS WG, and establishing some requirements for solutions.

=C2= =A0

Section 2 describes the model for I2RS. It calls for using existing transport protocols to provide security, a good statement as part of the base protocol requirements. Looking at Figure 1, it seems that the only paths that are in scope for I2RS are between an I2RS agent and client and between clients. =

In section 5= , authentication, authorization, and integrity are explicitly cited as requirements. This is a good statement of requirements. It might be nice to state whether confidentiality is also perceived as a requirement, or if it explicitly not a requirement.


The s= ad answer is that it depends on what data is being sent.=C2=A0 For instance= , I can see counters or events not requiring confidentiality (depending) bu= t some things being written or responses might require confidentiality.=C2=A0
I've added in
"=C2=A0Some communications = will also require confidentialit= y."
at the en= d of the Secure Control bullet.
=C2=A0

<= /div>

The Security Considerations section is a single paragraph consisting of 2 sentences. It opens with a nice statement about the importance of security in the I2RS context. I think a back pointer to the =E2=80=9Csecure Control=E2=80=9D text would be appropriate. The sec= ond sentence says that more investigation is needed to fully define security requirements such as authorization and authentication levels. I don=E2=80=99t know what this last phrase means. Authorization (aka access control) isn=E2=80=99t usually described as having levels pe= r se. Do you mean granularity of access control, or something else. Also, for authentication, there are various mechanisms one can employ, and these may be described as offering varying =E2=80=9Clev= els=E2=80=9D of security, but that is an oversimplification in many cases. A clearer description of what the authors are trying to convey here would be good.


I've updated the Security Considerations section to:

"Security is a key aspect of any protocol that allows state
=C2=A0 =C2=A0 =C2=A0 installation and extracting of detailed route= r state.=C2=A0 The need
=C2=A0 =C2=A0 =C2=A0 for secure control i= s mentioned in Section 5.=C2=A0 More architectural security
=C2= =A0 =C2=A0 =C2=A0 considerations are discussed in <xref
=C2=A0= =C2=A0 =C2=A0 target=3D"I-D.ietf-i2rs-architecture"/>.=C2=A0 = Briefly, the I2RS Agent
=C2=A0 =C2=A0 =C2=A0 is assumed to have a= separate authentication and authorization
=C2=A0 =C2=A0 =C2=A0 c= hannel by which it can validate both the identity and the
=C2=A0 = =C2=A0 =C2=A0 permissions associated with an I2RS Client.=C2=A0 Mutual
=C2=A0 =C2=A0 =C2=A0 authentication between the I2RS Agent and I2RS C= lient is
=C2=A0 =C2=A0 =C2=A0 required.=C2=A0 Different levels of= integrity, confidentiality, and
=C2=A0 =C2=A0 =C2=A0 replay prot= ection are relevant for different aspects of
=C2=A0 =C2=A0 =C2=A0= I2RS."
=C2=A0

I also looked briefly at draft-hares-i2rs-security-02. That document begins with a very good discussion of security terminology based on RFC 4949. It also proposes very specific security requirements for communications in the I2RS model. That document calls for confidentiality as a requirement, which further motivates some mention of this security service in the problem statement, even if the statement is equivocal.

=20 =20 =20 =20 =20 =20 =20 =20 =20 =C2=A0

=C2= =A0

Two typos I noted:

=C2= =A0

Section 2: measuresments -> measurements

=C2= =A0

Section 5:

=C2= =A0

Such communications must also have its integrity protected. ->=

=C2= =A0

Such communications must also be integrity-protected.


fixed=C2=A0


Thanks again,
Alia
--089e0122a476c61e05050c033016-- From nobody Tue Jan 6 22:34:30 2015 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 A65551A895C; Tue, 6 Jan 2015 22:34:28 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ujcrev2HYdz5; Tue, 6 Jan 2015 22:34:26 -0800 (PST) Received: from COL004-OMC4S3.hotmail.com (col004-omc4s3.hotmail.com [65.55.34.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BE71A8749; Tue, 6 Jan 2015 22:34:26 -0800 (PST) Received: from COL401-EAS231 ([65.55.34.201]) by COL004-OMC4S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 6 Jan 2015 22:34:26 -0800 X-TMN: [65HRksx9n8HuCMNeLT9wVZSv947W5blr] X-Originating-Email: [charliekaufman@outlook.com] Message-ID: From: Charlie Kaufman To: Date: Tue, 6 Jan 2015 22:34:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 thread-index: AdAqP+F8Wy95lMIdTFiL8C/lr4JixA== Content-Language: en-us X-OriginalArrivalTime: 07 Jan 2015 06:34:26.0108 (UTC) FILETIME=[FB4D7FC0:01D02A43] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PJuwDZ8lqZh9rMKofnzKILotOYo Cc: draft-ietf-mpls-in-udp.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-mpls-in-udp-09 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, 07 Jan 2015 06:34:28 -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.=A0 = These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments = just like any other last call comments. This document specifies a syntax for encapsulating MPLS in UDP for the purpose of tunneling MPLS packets across a non-MPLS portion of the = network. There are already RFCs specifying the encapsulation of MPLS in IP, GRE, = and L2TPv3. The motivation to specify yet another encoding is to take = advantage of the fact that many routers know how to load balance links based on = UDP ports, and this encoding gives the encapsulator the ability to take advantage of that. The security considerations follow other schemes for encapsulating MPLS, though there are some gotchas. If the tunnel is protected using IPsec, = the UDP ports are hidden and there is little to no reason to use this = protocol over the (slightly) more efficient MPLS over IP. Protecting the tunnel = using DTLS may be viable if the size of the DTLS header is not prohibitive. I would expect that it would be common for the tunnel to be unprotected = while the tunneled connections are protected with some cryptographic protocol (though this leaves the system open to network-overloading denial of = service attacks). I could find nothing to take issue with. Formatting glitch: At least on my system, Viewing the pdf version of the document shows page 4 as being reduced to about 1/4 of its correct size (i.e. 5 or 6 point font). --Charlie From nobody Wed Jan 7 07:52:07 2015 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 9953D1A8A89; Wed, 7 Jan 2015 05:26:07 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 gdZCvezzhtmf; Wed, 7 Jan 2015 05:26:04 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan5.extendcp.co.uk [79.170.43.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FAB1A8A84; Wed, 7 Jan 2015 05:26:04 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.extendcp.co.uk) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Y8qcd-00054a-1O; Wed, 07 Jan 2015 13:26:03 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Y8qcY-0004HI-RE; Wed, 07 Jan 2015 13:26:02 +0000 Received: from host86-167-170-172.range86-167.btcentralplus.com ([86.167.170.172] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Y8qcT-0004wQ-JG; Wed, 07 Jan 2015 13:25:54 +0000 Message-ID: <54AD33DA.5080006@gridmerge.com> Date: Wed, 07 Jan 2015 13:25:46 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Steve.Hanna@infineon.com, consultancy@vanderstok.org References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> In-Reply-To: <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090102040600000107010400" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/GpgFXhLLwMdXORzJKPmg8jJybsI X-Mailman-Approved-At: Wed, 07 Jan 2015 07:52:03 -0800 Cc: iesg@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 13:26:07 -0000 This is a cryptographically signed message in MIME format. --------------ms090102040600000107010400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Steve, My comments inline, bracketed by . Robert On 02/01/2015 18:26, Steve.Hanna@infineon.com wrote: > Peter, > > Thanks for your prompt response. I have added some more comments below,= > delimited with . > > Steve > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Friday, January 02, 2015 5:19 AM > To: Hanna Steve (IFNA CCS SMD AMR) > Cc: secdir@ietf.org; iesg@ietf.org; > draft-ietf-roll-admin-local-policy.all@tools.ietf.org > Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02 > > Dear Steve, > > thanks for the comments. I will respond below to the points you raise. > > Greetings, Peter > > Steve.Hanna@infineon.com schreef op 2014-12-30 13:55: > >> This document describes a technique for automatically managing the >> boundaries of the admin-local multicast scope in a border router, >> using MPL (Multicast Protocol for Low power and Lossy Networks). > > Correct > >> In my view, this document is Not Ready. >> >> The document is hard to understand. For example, the acronyms MPL and >> MPL4 are used throughout the document but they are not defined. > > You are the third to remark on this point. Adrian did suggestions to > improve the document with a definition of MPL, that we will take over. > MPL4 concepts are defined in section 1.2. > > > I'm happy to see that you'll be adding a definition of MPL. That's good= =2E > > While it's true that section 1.2 defines several terms that include MPL= 4 > (e.g., "MPL4 message"), the term "MPL4" is never defined anywhere. > I found that confusing. > >> After reading the document several times, I have concluded that >> section 3.2 contains the most important part of the document: an >> algorithm for automatically defining the boundaries of the admin-local= >> multicast scope using MPL. This section basically says that a border >> router should periodically send an MPL message on all interfaces to >> the ALL_MPL_FORWARDERS multicast address with admin-local scope. It >> should also listen for such messages on all interfaces. If it receives= >> such a message, that interface should be marked as part of the >> admin-local scope. >> >> This algorithm seems problematic from a security standpoint. Because >> any device on a network can send an MPL message to the >> ALL_MPL_FORWARDERS multicast address with admin-local scope, the >> boundaries of the admin-local multicast scope can be expanded by >> attackers fairly easily. I guess it depends what you mean by "fairly easily". An attacker in = this case would have interfaces on more than one network and would have=20 to be authenticated on all networks in question. The attack scenario may = be just to attach to one network and then forward into other network(s)=20 which would not originally be considered part of the admin-local scope=20 (which is I think what you are saying below) but it still has to=20 authenticate to the network being attacked and obtain the relevant key=20 before its interface on that network can validly receive a MPL4=20 message. >> Such manipulation may permit nodes that >> should be outside a particular administrative domain to join that >> domain and participate in receiving and sending multicast traffic >> within that domain. The implications of such an attack are not clear >> to me because I am not familiar with the protocols and devices that >> use admin-local multicast scope. However, it seems likely that >> expanding the admin-local multicast scope will permit external >> attackers to more easily monitor multicast traffic that should be >> private and to inject multicast messages into a relatively trusted >> domain. Again, it has to have been authenticated to one or more networks=20 and obtained the relevant key before it can do this. > > In the discussion with Joel, we came to the conclusion that we were not= > very clear with respect to the administrative zone specification. > We suggested to limit the mpl admin-local scope within one zone. > The text will be extended to include this extra limit on the boundary o= f > admin-local-scope. > The extent of the scope does not specify anything about the contents of= > the MPL messages. > It is expected that MPL messages are encrypted depending on the wanted > security level. > Monitoring by an attacker limits itself to counting messages, which is > already possible on wireless links any way. > To inject messages, the attacker should know the keys necessary to > encrypt. > When messages are not encrypted they are already readable on the > wireless links, and the monitoring by extending the mpl-admin-local > scope does not increase the vulnerability to snooping the messages. > > > Please send me a copy of your new text limiting the admin-local scope > to one zone. I don't see how this will help but maybe the new text will= > make it clear. > > You just stated that "It is expected that MPL messages are encrypted". > However, this is never stated in draft-ietf-roll-trickle-mcast-11.txt o= r in > draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no mention = of > encryption in those documents at all. If the security of your design > depends on this encryption, you'd better talk about it somewhere! > > Now I'd like to investigate the security provided by this encryption. > Are you expecting that application-layer encryption will be used? > I suppose not because that would require extensive description > And you provided none. Probably you're thinking about link-layer > encryption such as that provided by IEEE 802.11i. However, I don't > think that such encryption will prevent the attacks that I described. > > A border router frequently spans networks that are part of multiple > administrative domains. Your current design (even with link encryption)= > means that any device connected to any of these networks can dictate > the boundaries of the admin-local scope. Is it really desirable to trus= t > all those devices to that extent? I think not. > The concept of scope, network boundary and security boundary are all=20 somewhat orthogonal. RFC7346 acknowledges this with additional text and=20 draft-ietf-roll-admin-local-policy explains how automatic configuration=20 for realm-local scope occurs in relation to a network identifier, which=20 then links network boundary and realm-local scope. However, there isn't=20 necessarily a one-to-one correspondence between security boundary and=20 network boundary even though it often happens in practice, e.g. a WPA2=20 key for an 802.11 WLAN or network key for ZigBee IP WPAN, for example.=20 Assuming this link-layer encryption, I don't think the attacks can take=20 place as an attacker would have to authenticate itself to the network=20 being attacked first or else it would not be able to validly received=20 the MPL4 message. It is true that a border router configured with multiple MPL-enabled=20 interfaces does indeed by implication expand the admin-local scope,=20 however it is not obliged to have all its interfaces MPL-enabled; this=20 is part of configuration as well, potentially controllable by some=20 superordinate entity. Perhaps we need some extra text to explain this. > >> In addition to this fundamental concern, I have a few minor concerns >> about the readability of the document. However, I seem to have mislaid= >> my notes during the holidays. Because this review is already late and >> I'm on vacation, I will send the review now and follow up with the >> minor concerns at a later date if I can find them when I return to the= >> office. > > If you find terms which are not defined in this draft, > ietf-rol-trickle-mcast or RFC7346, I will be happy to extend the > definitions of section 1.2. > > > OK, I'll look for my notes. However, the most important aspect of > my review is the security issue described above. > > --------------ms090102040600000107010400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTAxMDcxMzI1NDZaMCMGCSqGSIb3DQEJBDEWBBTjXgmnawLm5pAHT8nJfveC2Ybi1TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQAhHGkEwGqxWcjUCIBFQF31cpNLeUoYTNNa A/cKT8zpGcfRFNewHi/P9HBl33zLzZhzdFw1BmA4U6LlGPCAeumUQjf6G3IM285Jlu01ZWqW yQDLd8kZb3C9Q6HH9BGSc98Qfe9HUZRg449Z5z2vF2lo4ClU1rNhyVPUGePHfG9vjrD/1hKX qbYWkrG00bZzxyWE4UINhAwcz933eGIE+/Dn+Ht1q4U3F+QdrQUgGxfDNxgugMs1SdaFjM0A N6QiM8es23sDthFf4oTdqWeb9Zex2vzJNmoO+NXv1Nwj0zWcOKFPLclQ1hZ28Pbhni0O70SZ DDMDBCTZGsidGvzIBzl+AAAAAAAA --------------ms090102040600000107010400-- From nobody Thu Jan 8 06:13:43 2015 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 7A7901A0231; Thu, 8 Jan 2015 06:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 X2fbawpqWw6e; Thu, 8 Jan 2015 06:13:37 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E151A3BA0; Thu, 8 Jan 2015 06:13:02 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t08ECvAS025132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Jan 2015 16:12:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t08ECv1x027788; Thu, 8 Jan 2015 16:12:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21678.36969.742906.415575@fireball.kivinen.iki.fi> Date: Thu, 8 Jan 2015 16:12:57 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-json-i-json.all@tools.ietf.org X-Edit-Time: 14 min X-Total-Time: 15 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-json-i-json-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, 08 Jan 2015 14:13:39 -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 describes the restricted version of the JSON called Internet JSON. This version of JSON is subset of the full JSON restricting some uses of the full JSON (i.e it says they MUST use UTF-8, and then it has several MUST NOTs and SHOULD NOTs limiting some versions of JSON). During the review process of the draft-ietf-jose-json-* there was lots of complains about those documents by secdir reviewers, because the text in the drafts which said that duplicate names can be parsed in several different ways. This document forbids having duplicate names, i.e. makes it MUST NOT. The security considerations section is very short only saying: All the security considerations which apply to JSON (see RFC 7159) apply to I-JSON. There are no additional security considerations specific to I-JSON. And the security considerations section in RFC7159 is also quite short, only warning about not using the eval when parsing json. I agree that as this is only restricting the use of JSON, this does not give any new security ocnsiderations, although I would have expected the original JSON to have bit longer security considerations section (especially as the format is not very simple and there are easy ways to mess up things, but on the other hand most of security considerations issues are going to be in the applications or protocols using the JSON, not the actual JSON definition itself). Anyways it might be good idea to add text to the security considerations section, that as I-JSON restricts and limits some of the dangerous formats of the original JSON, it might be considered to be more secure than the original JSON, and perhaps also mention that security critical usages of the JSON should use I-JSON instead of JSON (perhaps even provide references to the jose specifications). In general I think the document is ready. -- kivinen@iki.fi From nobody Thu Jan 8 06:23:04 2015 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 B22911A00C6 for ; Thu, 8 Jan 2015 06:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 NortJqnqW82h for ; Thu, 8 Jan 2015 06:22:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B2B1A0012 for ; Thu, 8 Jan 2015 06:22:58 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t08EMvTd027878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 8 Jan 2015 16:22:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t08EMvvI005056; Thu, 8 Jan 2015 16:22:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21678.37569.216223.942682@fireball.kivinen.iki.fi> Date: Thu, 8 Jan 2015 16:22:57 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: 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, 08 Jan 2015 14:23:01 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sandy Murphy is next in the rotation. For telechat 2015-01-08 Reviewer LC end Draft Alan DeKok T 2015-01-01 draft-higgs-hbbtv-urn-00 David Waltermire T 2014-12-09 draft-ietf-kitten-cammac-00 For telechat 2015-01-22 Sam Hartman T 2015-01-09 draft-farrkingel-pce-abno-architecture-14 Ben Laurie T 2015-01-08 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-14 Matt Lepinski T 2015-01-14 draft-ietf-httpbis-header-compression-10 Chris Lonvick T 2015-01-14 draft-ietf-httpbis-http2-16 For telechat 2015-02-05 Adam Montville T 2015-01-20 draft-ietf-ospf-ospfv3-autoconfig-10 Last calls and special requests: Dorothy Gellert 2014-12-22 draft-ietf-ippm-rate-problem-08 Tobias Gondrom 2014-12-18 draft-ietf-mpls-ldp-ipv6-14 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-12-22 draft-ietf-tsvwg-port-use-06 David Harrington 2014-12-24 draft-ietf-tsvwg-sctp-dtls-encaps-07 Paul Hoffman 2015-01-08 draft-holmberg-dispatch-iotl-03 Jeffrey Hutzelman 2015-01-22 draft-ietf-drinks-spp-protocol-over-soap-07 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Leif Johansson 2014-12-25 draft-ietf-radext-radius-fragmentation-09 Warren Kumari 2015-01-17 draft-ietf-ccamp-general-constraint-encode-16 Catherine Meadows 2015-01-26 draft-ietf-l2vpn-pbb-evpn-09 Alexey Melnikov 2015-01-14 draft-ietf-opsawg-coman-probstate-reqs-03 Matthew Miller 2015-01-14 draft-ietf-opsawg-coman-use-cases-03 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-08 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 -- kivinen@iki.fi From nobody Sun Jan 11 12:20:51 2015 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 AC21A1A1A20 for ; Sun, 11 Jan 2015 12:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 Kph-OwyhVdH9 for ; Sun, 11 Jan 2015 12:20:47 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1A21A6F0A for ; Sun, 11 Jan 2015 12:20:47 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so16131284wgg.10 for ; Sun, 11 Jan 2015 12:20:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ezhFJXweCcUeS/2TwCd5wL8II6rdllABnCXjQPHdkTA=; b=cXrgvY8hv0RGwtvvRDqmAcQsi8Xwb0QxVCihFPTuTxbgb6YNI8fLODKAwlIvuTbxKk n2DplaEig9ebKj0h51d0i/KLNyqgWmY+5apCEN/MsQHkFxRrOhKfUBDKJqRZGWLfhJOx QrfDYs5u9cfK5BUC/28r6BgwMGhcwdQ/5hHRZX5SabHx8R4m081aRwmwXNtPbq2UnRvI 3TDQ8Ly7AAEJRH1x+qXd4JqJfKpQMHxaNnNFfB0D+WgRwg7/f9VVfdxGPggvqsKeWAyj VUwSlJvpdCN3F0GY/MfUtCPR6CK5SRBKeNCbYijxkMV3m+glG/R3xNRxfTuAkolXn89b J79g== X-Gm-Message-State: ALoCoQm+mDLKAXuK4zu1/kDKXq2DlpBo7xJg4ZfiJPtONbHpZyDh16Cw5pwmiGcpfhQJCGgd5My/ MIME-Version: 1.0 X-Received: by 10.180.198.51 with SMTP id iz19mr23750258wic.65.1421007645797; Sun, 11 Jan 2015 12:20:45 -0800 (PST) Received: by 10.194.64.37 with HTTP; Sun, 11 Jan 2015 12:20:45 -0800 (PST) Date: Sun, 11 Jan 2015 15:20:45 -0500 Message-ID: From: Warren Kumari To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] SecDir review of draft-ietf-ccamp-general-constraint-encode 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, 11 Jan 2015 20:20:49 -0000 Be ye not alarmed... 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: Ready with nits. Summary: This draft contains a Standards Track document on encoding label and connectivity constraints on GMPLS controlled networks. It also has some wicked ASCII art.... I'm not really a GMPLS person, and so some of the constraints that this discussed hadn't really occurred to me (like some gear not being able to do wavelength conversion -- by the time I see a link its in a router :-)). Anyway, this seem like a real problem, and the solution seems reasonable. >From a security standpoint I couldn't really see much issue here -- I guess a suitably placed attacker could signal additional constraints, either forcing paths to be built past a place where he could intercept them, or adding constraints that prevent paths from being built at all. An attacker with this level of access has already won, and so I don't view this as a major issue. I *do* however have a pile o' nits, see below, in COPE (Comment, Original, Proposed, Error) format. These are all readability / grammar, no substantive changes below.... Abstract Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network [O]In some of these technologies network [P] In some of these technologies, network [C] grammar elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. [ SNIP ] 1.1. Node Switching Asymmetry Constraints For some network elements the ability of a signal or packet on a [O] For some network elements the ability [P] For some network elements, the ability [C] grammar/readability particular input port to reach a particular output port may be limited. In addition, in some network elements the connectivity between some input ports and output ports may be fixed, e.g., a simple multiplexer. To take into account such constraints during path computation we model this aspect of a network element via a [O] path computation we model [P] path computation, we model [C] grammar/readability connectivity matrix. The connectivity matrix (ConnectivityMatrix) represents either the potential connectivity matrix for asymmetric switches or fixed connectivity for an asymmetric device such as a multiplexer. Note that this matrix does not represent any particular internal blocking behavior but indicates which input ports and labels (e.g., wavelengths) could possibly be connected to a particular output port and label pair. Representing internal state dependent blocking for a node is beyond the scope of this document and due to it's highly implementation dependent nature would most likely not be subject to [O] and due to it's highly implementation dependent nature would most [P] and, due to its highly implementation-dependent nature, would most [C] apostrophe removed and two commas added; grammar/readability standardization in the future. The connectivity matrix is a conceptual M*m by N*n matrix where M represents the number of input ports each with m labels and N the number of output ports each with n labels. 1.2. Non-Local Label Assignment Constraints If the nature of the equipment involved in a network results in a requirement for non-local label assignment we can have constraints [O] for non-local label assignment we can have [P] for non-local label assignment, we can have [C] grammar/readability based on limits imposed by the ports themselves and those that are implied by the current label usage. Note that constraints such as these only become important when label assignment has a non-local character. For example in MPLS an LSR may have a limited range of labels available for use on an output port and a set of labels already in use on that port and hence unavailable for use. This [O] For example in MPLS an LSR may have a limited range of labels available for use on an output port and a set of labels already in use on that port and hence unavailable for use. [P] For example, in MPLS an LSR may have a limited range of labels available for use on an output port, and a set of labels already in use on that port, and hence unavailable for use. [C] grammar/readability information, however, does not need to be shared unless there is some limitation on the LSR's label swapping ability. For example if a TDM node lacks the ability to perform time-slot interchange or a WSON lacks the ability to perform wavelength conversion then the label assignment process is not local to a single node and it may be advantageous to share the label assignment constraint information for use in path computation. [O] For example if a TDM node lacks the ability to perform time-slot interchange or a WSON lacks the ability to perform wavelength conversion then the label assignment process is not local to a single node and it may be advantageous to share the label assignment constraint information for use in path computation. [P] For example, if a TDM node lacks the ability to perform time-slot interchange, or a WSON lacks the ability to perform wavelength conversion, then the label assignment process is not local to a single node. In this case, it is may be advantageous to share the label assignment constraint information for use in path computation. [C] run on sentence; broken up and punctuated for readability. Port label restrictions (PortLabelRestriction) model the label restrictions that the network element (node) and link may impose on a port. These restrictions tell us what labels may or may not be [ SNIP ] The Connectivity Matrix Field represents how input ports are connected to output ports for network elements. The switch and fixed connectivity matrices can be compactly represented in terms of a minimal list of input and output port set pairs that have mutual connectivity. As described in [Switch] such a minimal list [O] As described in [Switch] such a minimal list [P] As described in [Switch], such a minimal list [C] grammar/readability representation leads naturally to a graph representation for path computation purposes that involves the fewest additional nodes and links. [SNIP] o Link Set A dir=input, Link Set B dir=output The meaning of the pair of link sets A and B in this case is that any signal that inputs a link in set A can be potentially switched out of an output link in set B. [O] The meaning of the pair of link sets A and B in this case is that any signal that inputs a link in set A can be potentially switched out of an output link in set B. [P] In this case, the meaning of the pair of link sets A and B is that any signal that inputs a link in set A can be potentially switched out of an output link in set B. [C] readability o Link Set A dir=bidirectional, Link Set B dir=bidirectional [SNIP] The port label restriction can be encoded as follows: More than one of these fields may be needed to fully specify a complex port constraint. When more than one of these fields are present the [O] When more than one of these fields are present the [P] When more than one of these fields are present, the [C] grammar resulting restriction is the union of the restrictions expressed in each field. To indicate that a restriction applies to the port in general and not to a specific connectivity matrix use the reserved value of 0xFF for the MatrixID. [O] To indicate that a restriction applies to the port in general and not to a specific connectivity matrix use the reserved value of 0xFF for the MatrixID. [P] Use the reserved value of 0xFF for the MatrixID to indicate that a restriction applies to the port. [C] grammar/readability [BIG SNIP] 3. Security Considerations This document defines protocol-independent encodings for WSON information and does not introduce any security issues. However, other documents that make use of these encodings within protocol extensions need to consider the issues and risks associated Bernstein and Lee Expires June 29, 2015 [Page 17] Internet-Draft General Network Element Constraint Encoding December 2014 with, inspection, interception, modification, or spoofing of any of [O] with, inspection [P] with inspection [R] no comma needed -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Jan 12 05:27:51 2015 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 33FEC1A0191; Mon, 12 Jan 2015 05:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNS4W6dhqgmj; Mon, 12 Jan 2015 05:11:46 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07BF1A8F40; Mon, 12 Jan 2015 05:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23258; q=dns/txt; s=iport; t=1421068305; x=1422277905; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VxZGX1yo92iLPJhDNYzfz7nkJGBOcEDN8dxDaVqXQQo=; b=XOpidDE15TPP8m1TpK2rFfUTBGYD4PcV/6tPhPPgknDaHEXVTiV9zVRs LrLxnEuixk3YHQJDL5ruN/rMkF94bBGr3pgohyijuakGsKg74Oq4XCxRf D0wiwZL6Bj8siHa1cb7ubE10NKoRlBNtvlLmJn006Kz8pHBnGM4Nph2bG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisGAMTGs1StJV2b/2dsb2JhbABbDoJ4gS6DAchtAhx0QwEBAQEBfYQMAQEBAwEjETEUBQsCAQgYAgIRFQICAjAVEAIEDgUbiAkIuGCTLgEBAQEBAQEBAQEBAQEBAQEBAQEBGIEhiG6FGQEBTwcKgl4ugRMFjj2FDT6DQoEPhSyFIoJhgzoigzE9b4EMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,744,1413244800"; d="scan'208";a="112449197" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 12 Jan 2015 13:11:44 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0CDBiPP012534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 13:11:44 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 07:11:44 -0600 From: "Paul Quinn (paulq)" To: Benjamin Kaduk Thread-Topic: secdir review of draft-ietf-sfc-problem-statement-10 Thread-Index: AQHQJu3NUV+ytZVaUEqiubZyPy2He5y86VWA Date: Mon, 12 Jan 2015 13:11:43 +0000 Message-ID: <8C00C887-4A6A-481F-A472-6081FD4DC895@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: <5ADD502310FC1A4E83C5F55E43A051C4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 12 Jan 2015 05:27:49 -0800 Cc: "tnadeau@lucidvision.com" , "Joel M. Halpern" , "draft-ietf-sfc-problem-statement.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-sfc-problem-statement-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: Mon, 12 Jan 2015 13:11:50 -0000 QmVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3IGFuZCBzb3JyeSBmb3Ig dGhlIGRlbGF5ZWQgcmVwbHkgZHVlIHRvIHRoZSBob2xpZGF5cy4NCg0KSSBhZGRlZCBzb21lIGNv bW1lbnRzIGlubGluZSBiZWxvdy4gIEnigJl2ZSBhbHNvIGNj4oCZZCBvdXIgZG9jdW1lbnQgc2hl cGhlcmQsIEpvZWwsIHNpbmNlIEnigJltIG5vdCBzdXJlIGhlIHdhcyBvbiB0aGUgb3JpZ2luYWwg ZGlzdHJpYnV0aW9uLg0KDQpQYXVsDQoNCj4gT24gSmFuIDIsIDIwMTUsIGF0IDc6MzkgUE0sIEJl bmphbWluIEthZHVrIDxrYWR1a0BNSVQuRURVPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4gDQo+ IFNvcnJ5IHRoaXMgaXMgYSBiaXQgbGF0ZS4NCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRv Y3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCj4gb25nb2luZyBl ZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhl DQo+IElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9m IGltcHJvdmluZw0KPiBzZWN1cml0eSByZXF1aXJlbWVudHMgYW5kIGNvbnNpZGVyYXRpb25zIGlu IElFVEYgZHJhZnRzLiAgQ29tbWVudHMNCj4gbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5 IGJlIGluY2x1ZGVkIGluIEFEIHJldmlld3MgZHVyaW5nIHRoZQ0KPiBJRVNHIHJldmlldy4gIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UNCj4gY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBJIGJlbGll dmUgdGhpcyBkb2N1bWVudCBpcyBub3QgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KPiANCj4gVGhl IGRvY3VtZW50IGF0dGVtcHRzIHRvIGRpc2NsYWltIHRoZSBuZWVkIGZvciBhIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zDQo+IHNlY3Rpb24gYnkgdmlydHVlIG9mIGJlaW5nIGEgcHJvYmxlbS1zdGF0 ZW1lbnQgb25seSBkb2N1bWVudC4gIEhvd2V2ZXIsDQo+IHNlY3Rpb24gMyBwcm92aWRlcyB0aHJl ZSBjb21wb25lbnRzIHdoaWNoIGFyZSBleHBlY3RlZCB0byBiZSBwYXJ0IG9mDQo+IHNvbHV0aW9u cyB0byB0aGUgcHJvYmxlbSwgYW5kIHRoZSBmb2N1cyBvZiBmdXR1cmUgd29yayBpbiB0aGUgd29y a2luZw0KPiBncm91cC4gIEV2ZW4gYXQgdGhpcyBhYnN0cmFjdCBsZXZlbCwgdGhlcmUgYXJlIHN0 aWxsIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIHRoYXQgY2FuIGJlIG1hZGUsIGFuZCBJJ20g c3VyZSBJIHdpbGwgbm90IHRoaW5rIG9mIGFsbCBvZg0KPiB0aGVtIGR1cmluZyB0aGUgY291cnNl IG9mIHRoaXMgcmV2aWV3Lg0KPiANCj4gQWRkaXRpb25hbGx5LCB0aGVyZSBhcmUgc3VmZmljaWVu dGx5IG1hbnkgZ3JhbW1hciBhbmQgbGFuZ3VhZ2Ugb2RkaXRpZXMNCj4gYW5kIGluY29uc2lzdGVu Y2llcyBpbiB0aGUgdGV4dCB0byBiZSBkaXN0cmFjdGluZyBmcm9tIHRoZSBhY3R1YWwgY29udGVu dA0KPiBvZiB0aGUgZG9jdW1lbnQ7IEknbGwgdHJ5IHRvIGNvdmVyIHRob3NlIGF0IHRoZSBlbmQg b2YgdGhpcyBtYWlsLiAgVXNpbmcNCj4gbXVsdGlwbGUgdGVybXMgZm9yIHRoZSBzYW1lIGNvbmNl cHQgZG9lc24ndCBoZWxwLCBlaXRoZXIgKGFzIGlzIGRpc2NsYWltZWQNCj4gaW4gdGhlIGRlZmlu aXRpb25zIHNlY3Rpb24pLCBidXQgSSB1bmRlcnN0YW5kIGhvdyB0aGF0IGlzIHVuYXZvaWRhYmxl IGluDQo+IHRoaXMgY2FzZS4NCj4gDQo+IA0KPiBUbyByZS1zdW1tYXJpemUgdGhlIGRvY3VtZW50 IChzZWN0aW9uIDUgbm90d2l0aHN0YW5kaW5nKSwgaXQgbGF5cyBvdXQgc29tZQ0KPiB0ZXJtaW5v bG9neSBhbmQgcHJvdmlkZXMgYSBsaXN0IG9mIG1hbnkgb2YgdGhlIGlzc3VlcyBpbnZvbHZlZCBp biBzZXR0aW5nDQo+IHVwIGEgY29tcGxpY2F0ZWQgdHJhZmZpYyBwcm9jZXNzaW5nIHNjaGVtZSBp bnZvbHZpbmcgbXVsdGlwbGUgbmV0d29yaw0KPiBzZXJ2aWNlIGZ1bmN0aW9ucyAoZmlyZXdhbGxz LCB0cmFmZmljIGFjY2VsZXJhdG9ycywgbG9hZCBiYWxhbmNpbmcsIGV0Yy4pDQo+IHVzaW5nIGN1 cnJlbnQgdGVjaG5vbG9naWVzLiAgVGhlIGRpZmZpY3VsdGllcyBsYXJnZWx5IHN0ZW0gZnJvbSB0 aGUgdGlnaHQNCj4gY291cGxpbmcgYmV0d2VlbiB0aGUgbmV0d29yayB0b3BvbG9neSBhbmQgdGhl IHdheS9vcmRlciBpbiB3aGljaCBzZXJ2aWNlDQo+IGZ1bmN0aW9ucyBhcmUgYXBwbGllZCB0byB0 cmFmZmljLiAgVGhyZWUgY29tcG9uZW50cyBhcmUgZGlzY3Vzc2VkIHdoaWNoDQo+IHdpbGwgaGVs cCBicmVhayB0aGlzIGNvdXBsaW5nOiBhICJzZXJ2aWNlIG92ZXJsYXkiLCB3aGljaCBhbGxvd3Mg Zm9yIHRoZQ0KPiBzZXJ2aWNlLWZ1bmN0aW9uLWNoYWluIHRvcG9sb2d5IHRvIGJlIGRlY291cGxl ZCBmcm9tIHRoZSBuZXR3b3JrIHRvcG9sb2d5Ow0KPiAic2VydmljZSBjbGFzc2lmaWNhdGlvbiIg dG8gY29udHJvbCB0cmFmZmljIGZsb3cgb24gdGhlIHNlcnZpY2Ugb3ZlcmxheQ0KPiB0b3BvbG9n eTsgYW5kICJkYXRhcGxhbmUgbWV0YWRhdGEiIHRvIGNvbnZleSB0aGUgY2xhc3NpZmljYXRpb24g ZGF0YSAoYW5kDQo+IG90aGVyIGRhdGEpLg0KPiANCj4gDQo+IA0KPiBIZXJlIGFyZSB0aGUgcG90 ZW50aWFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIEkgY2FtZSB1cCB3aXRoIHNvIGZhcjoNCj4g DQo+ICogQW4gZXJyb3IgaW4gc2VydmljZSBjbGFzc2lmaWNhdGlvbiBjb3VsZCBsZWFkIHRvIHVu dHJ1c3RlZCB0cmFmZmljDQo+IGZsb3dpbmcgdGhyb3VnaCBhIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW4gaW50ZW5kZWQgZm9yIHRydXN0ZWQgdHJhZmZpYw0KPiBvbmx5LiAgSW4gdmFyaW91cyBoeXBv dGhldGljYWwgc2l0dWF0aW9ucywgdGhpcyBjb3VsZCBsZWFkIHRvIGFuIGF0dGFja2VyDQo+IGJl aW5nIGFibGUgdG8gZXhlY3V0ZSBwcml2aWxlZ2VkIGFjdGlvbnMgdmlhIGEgdHJ1c3RlZCBzZXJ2 aWNlLCBleGVjdXRlIGENCj4gRG9TIGF0dGFjayBhZ2FpbnN0IGFuIGludGVybmFsIHNlcnZpY2Us IGV0Yy4gIEl0IGlzIGltcG9ydGFudCBmb3Igc2VydmljZQ0KPiBjbGFzc2lmaWNhdGlvbiB0byAi ZmFpbCBzYWZlIiB0byBhdm9pZCB0aGlzIGNsYXNzIG9mIGlzc3Vlcy4gICgiRmFpbGluZw0KPiBz YWZlIiBtaWdodCBvciBtaWdodCBub3QgaW5jbHVkZSBqdXN0IGRyb3BwaW5nIHN1Y2ggdHJhZmZp Yy4pDQoNClBRPiAgVGhpcyBzdGF0ZW1lbnQgYXBwbGllcyB0byBhbGwgdGhpbmdzIHRoYXQgZGVw ZW5kIG9uIGNsYXNzaWZpY2F0aW9uLCBvciBjb25maWd1cmF0aW9uIGluIGdlbmVyYWwuICBQZXJo YXBzIGEgc3RhdGVtZW50IGFib3V0IOKAnHJpc2sgYXNzb2NpYXRlZCB3aXRoIGNvbmZpZ3VyYXRp b24gb3Igb3RoZXIgb3BlcmF0aW9uYWwgZXJyb3Jz4oCdIGFuZCBzZXJ2aWNlIGNoYWluaW5nIHdv dWxkIGhlbHAgY2xhcmlmeS4NCg0KDQo+IA0KPiAqIFNpbWlsYXJseSwgZXJyb3JzIGluIHRyYW5z bGF0aW5nIGZyb20gYW4gZXhpc3RpbmcgbmV0d29yay9zZXJ2aWNlDQo+IHRvcG9sb2d5IHRvIGEg c2VwYXJhdGUgc2VydmljZSBvdmVybGF5IChlLmcuLCBvbWlzc2lvbiBvciBhZGRpdGlvbiBvZiBh DQo+IGZpcmV3YWxsIGVsZW1lbnQpIGNvdWxkIGxlYWQgdG8gYW4gYXR0YWNrZXIgc2VuZGluZyB0 cmFmZmljIGluIHRoZSByZWFsDQo+IG5ldHdvcmsgdG8gc2VydmljZXMgd2hpY2ggb3VnaHQgdG8g YmUgZGlzYWxsb3dlZCBieSB0aGUgc2VydmljZSBvdmVybGF5Lg0KDQpQUT4gIFRoZSBhYm92ZSBz dWdnZXN0ZWQgc3RhdGVtZW50IChvciBzb21ldGhpbmcgc2ltaWxhcikgd291bGQgY292ZXIgdGhp cyBhcyB3ZWxsLg0KDQoNCg0KPiANCj4gKiBUaGUgZGF0YXBsYW5lIG1ldGFkYXRhIGNvdWxkIG9w ZW4gdXAgYSBnaWFudCByYWJiaXQgaG9sZSBvZiBpbmZvcm1hdGlvbg0KPiBsZWFrYWdlLiAgSXQg aXMgdGVtcHRpbmcgdG8gc2F5IHRoYXQgdGhlIG1ldGFkYXRhIHdvdWxkIG9ubHkgZmxvdyBpbnNp ZGUNCj4gdGhlIG5ldHdvcmsgYm91bmRhcmllcyBvZiBhIHNpbmdsZSAoY29ycG9yYXRlKSBlbnRp dHksIGJ1dCAiU1NMIGFkZGVkIGFuZA0KPiByZW1vdmVkIGhlcmUgOi0pIiBzaG91bGQgY29udmlu Y2UgdXMgdGhhdCB0aGF0J3Mgbm90IGEgd29ya2FibGUgc29sdXRpb24uDQo+IE1ldGFkYXRhIGNv dWxkIGNvbmNlaXZhYmx5IGluY2x1ZGUgdGhlIHR5cGUgb2YgdHJhZmZpYywgY2xpZW50IGluZm9y bWF0aW9uDQo+IChpLmUuLCBwZXJzb25hbGx5IGlkZW50aWZ5aW5nIGluZm9ybWF0aW9uKSwgYW5k IG1vcmUsIHNvbWUgb2Ygd2hpY2ggc2hvdWxkDQo+IHJlY2VpdmUgcHJvdGVjdGlvbiBmcm9tIGVh dmVzZHJvcHBlcnMgb24gdGhlIGRhdGFwbGFuZSB3aGljaCB3aWxsIG5vdCBuZWVkDQo+IHRvIHBy b2Nlc3MgdGhlIHRyYWZmaWMgaW4gcXVlc3Rpb24uDQoNClBRPiAgVGhlIOKAnHZhbHVl4oCdIG9m IHRoZSBtZXRhZGF0YSBpcyBoaWdobHkgdmFyaWFibGUsIGluIHNvbWUgZW52aXJvbm1lbnRzLCBh cyB5b3UgcG9pbnQgb3V0LCBpdCBtaWdodCBiZSBzZW5zaXRpdmUuICBQZXJoYXBzIHdlIGNhbiBh ZGQgdGhlIGZvbGxvd2luZyB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbnM6 DQoNCjEuICBJZiBkYXRhIHBsYW5lIGNvbmZpZGVudGlhbGl0eSBvciBpbnRlZ3JpdHkgaXMgcmVx dWlyZWQsIGEgdHJhbnNwb3J0IHRoYXQgc3VwcG9ydHMgdGhlIHJlcXVpc2l0ZSBmdW5jdGlvbmFs aXR5IChlLmcuIElQU2VjKSBzaG91bGQgYmUgdXNlZCB0byBjcmVhdGUgdGhlIHNlcnZpY2Ugb3Zl cmxheS4NCg0KMi4gIFNpbWlsYXJseSwgY29udHJvbCBwbGFuZSBtZXNzYWdlcyBtYXkgYmUgYXV0 aGVudGljYXRlZCBvciBlbmNyeXB0ZWQsIGFzIHJlcXVpcmVkIGJ5IGFuIG9wZXJhdG9yLCB1c2lu ZyBleGlzdGluZyBtZWNoYW5pc21zIChlLmcuIFNTTCkNCg0KDQoNCj4gDQo+ICogTWV0YWRhdGEg Y2FuIGNvbWUgZnJvbSAiZXh0ZXJuYWwgc291cmNlcyIuICBUaG9zZSBzb3VyY2VzIHNob3VsZCBi ZQ0KPiB0cnVzdHdvcnRoeSBhbmQgdmVyaWZpZWQsIG9yIGF0dGFja2VycyBjb3VsZCBzZW5kIHRy YWZmaWMgd2hlcmUgdGhleQ0KPiBvdWdodG4ndCBiZSBhYmxlIHRvLg0KDQpQUT4gIENvdmVyZWQg YnkgdGhlIGFib3ZlIGNvbnRyb2wgcGxhbmUgdGV4dC4NCg0KDQoNCj4gDQo+IA0KPiANCj4gSGVy ZSdzIHRoZSBncmFtbWFyIGFuZCBsYW5ndWFnZSBpc3N1ZXMgdGhhdCBib3RoZXJlZCBtZSwgcm91 Z2hseSBzb3J0ZWQNCj4gd2l0aCB0aGUgbW9yZSBpbXBvcnRhbnQgb25lcyBjb21pbmcgZmlyc3Qg YW5kIG90aGVyd2lzZSBpbiBvcmRlciBvZg0KPiBhcHBlYXJhbmNlOg0KPiANCj4gU2VjdGlvbiAz IGhhcyB0aGUgdGV4dCAidGhlIFNGQyB3b3JraW5nIGdyb3VwIHdpbGwgWy4uLl0iLCB3aGljaCBz ZWVtcw0KPiBtb3JlIGFwcHJvcHJpYXRlIGZvciBhIFdHIGNoYXJ0ZXIgdGhhbiBhbiBpbmZvcm1h dGlvbmFsIFJGQy4gIEkgc2VlIHRoaXMNCj4gaGFkIGJlZW4gYnJvdWdodCB1cCBpbiBkaXNjdXNz aW9uIG9mIHRoZSAtMDMsIGJ1dCBJIGRpZCBub3Qgc2VlIGFueQ0KPiBvYnZpb3VzIHJlc29sdXRp b24gaW4gYSBxdWljayBza2ltLiAgVG8gYmUgY2xlYXIsIEkgd291bGQgYmUgZmluZSB3aXRoDQo+ IHNvbWV0aGluZyB0aGF0IGRpZG4ndCBleHBsaWNpdGx5IHNheSB3aGF0IHRoZSBXRyB3b3VsZCBk bywgbGlrZSAiU0ZDIG1heQ0KPiBpbmNsdWRlIHNvbHV0aW9ucyB1dGlsaXppbmcgdGhlIGZvbGxv d2luZyBlbGVtZW50cyIgb3Igc29tZXRoaW5nIHNpbWlsYXIuDQoNClBRPiAgVGhlIGNvbXBsZXRl IGN1cnJlbnQgdmVyc2lvbiBzdGF0ZXM6IOKAnC4uLndpbGwgaW52ZXN0aWdhdGUgc29sdXRpb25z IHRoYXQgYWRkcmVzcyB0aGUgZm9sbG93aW5nIGVsZW1lbnRzOi4u4oCdIHdoaWNoIHdhcyB3aWRl bHkgcmV2aWV3ZWQgYW5kIGFjY2VwdGVkIHRoZSBXRyBtZW1iZXJzLg0KDQoNCj4gDQo+IFRoZSBk b2N1bWVudCB1c2VzIHNvbWUgYWNyb255bXMgdGhhdCBhcmUgbm90IGV4cGFuZGVkLiAgSSBleHBl Y3QgbW9zdA0KPiByZWFkZXJzIHRvIGJlIGZhbWlsaWFyIHdpdGggc29tZSwgYnV0IG5vdCBhbGws IG9mOg0KPiAqIE9wZW4gU3lzdGVtcyBJbnRlcmNvbm5lY3Rpb24NCj4gKiB0aGUgT1NJIG1vZGVs LCBlLmcuLCBsYXllciAzLCBsYXllciA3LCBldGMuIChJIGhhZCB0byB0aGluayBhIG1vbWVudA0K PiBhYm91dCAiTDQtTDciKQ0KPiAqIHRyYW5zbWlzc2lvbiBjb250cm9sIHByb3RvY29sDQo+ICog VmlydHVhbCBMb2NhbCBBcmVhIE5ldHdvcmsNCj4gKiBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbA0K PiAqIGludGVybmV0IHByb3RvY29sDQo+ICogdmlydHVhbCBwcml2YXRlIG5ldHdvcmsNCj4gKiBt dWx0aXByb3RvY29sIGxhYmVsIHN3aXRjaGluZw0KPiAqIFdpZGUgQXJlYSBOZXR3b3JrDQo+ICog ZGF0YWNlbnRlcg0KDQpQUT4gIEFzIHlvdSBwb2ludCBvdXQsIG1hbnkgb2YgdGhlc2UgYXJlIHdl bGwga25vd24gdGVybXMgdG8gcmVhZGVycyBvZiB0aGUgZHJhZnQsIGFzIHdhcyB0aGUgY2FzZSB3 aXRoIHRoZSByZXZpZXdlcnMuDQoNCg0KPiANCj4gSSBjYW4ndCBmaW5kIGEgcGFyc2UgdGhhdCBJ J20gaGFwcHkgd2l0aCBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24NCj4gMy4zLiAg SW4gcGFydGljdWxhciwgSSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIGxlYWRpbmcgIkFzIHN1Y2gi IGlzIGp1c3QgYQ0KPiB0cmFuc2l0aW9uIGxlYWRpbmcgaW50byBhIG5ldyBzZW50ZW5jZSAoZXF1 aXZhbGVudCB0byAiVGh1cywiKSwgaW4gd2hpY2gNCj4gY2FzZSBpdCBzaG91bGQgYmUgb2Zmc2V0 IGJ5IGEgY29tbWEsIG9yIGlmIHRoZSAic3VjaCIgYmluZHMgdG8gIm1ldGFkYXRhIg0KPiAoZXF1 aWF2ZW50IHRvICJTaW5jZSBzdWNoIikuICBJbiB0aGUgZmlyc3QgdmVyc2lvbiwgSSBndWVzcyB0 aGUgbWV0YWRhdGENCj4gaXMgc3VwcG9zZWQgdG8gYmUgc2VudCBvdXQtb2YtYmFuZCBhbmQgaW50 ZXJwcmV0ZWQgYnkgZnVuY3Rpb25zIGFsb25nIHRoZQ0KPiBzZXJ2aWNlIG92ZXJsYXksIGJ1dCBJ IGRvbid0IHNlZSBob3cgaXQgd291bGQgdGhlbiAqbm90KiBiZSB1c2VkIHRvDQo+IGNvbnRyb2wg dGhlIHJvdXRlIGJ5IHdoaWNoIHBhY2tldHMgdHJhdmVsLiAgSW4gdGhlIGxhdHRlciB2ZXJzaW9u LCB0aGUNCj4gc2VudGVuY2UgaXMgaW5jb21wbGV0ZSwgc2luY2UgdGhlcmUncyBubyBkZXBlbmRl bnQgY2xhdXNlLg0KPiANCg0KUFE+ICBBcyBzdWNoIGRvZXMgbm90IG1lYW4g4oCcdGh1c+KAnSwg dGh1cyAoOy0pKSB0aGUgc2VudGVuY2UgY2FuIHJlYWQ6DQoNCiJBcyBzdWNoIGl0IGlzIG5vdCB1 c2VkIGFzIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gdG8gZGVsaXZlciBwYWNrZXRzIGFsb25nIHRo ZSBzZXJ2aWNlIG92ZXJsYXkuIg0KDQpIYXZpbmcgc2FpZCB0aGF0LCBpdOKAmXMgcHJldHR5IG1p bm9yIHBvaW50LCBhbmQgY2FuIGJlIGZpeGVkIHNldmVyYWwgd2F5cyBpZiByZWFkZXIgZmluZCBp dCBjb25mdXNpbmcvb2ZmZW5zaXZlOg0KDQotICBJIGJlbGlldmUgdGhlIGNvcnJlY3QgdXNlIG9m IOKAnGFzIHN1Y2jigJ0gaW4gdGhpcyBjb250ZXh0IGlzIHRvIHJlbW92ZSB0aGUgd29yZCBtZXRh ZGF0YSBpbW1lZGlhdGVseSBmb2xsb3dpbmcg4oCcYXMgc3VjaOKAnS4gDQotIEFzIHN1Y2gg4oCU PiBNZXRhZGF0YSAoaS5lLiByZW1vdmUgYXMgc3VjaCkNCg0KDQo+IEluIHRoZSB0aGlyZCBwYXJh Z3JhcGggb2Ygc2VjdGlvbiAzLjMsIHRoZSBzZW5zZSBvZiB0aGUgdHdvIHRoaW5ncw0KPiBhZGRy ZXNzaW5nIGlzc3VlcyBzZWVtcyByZXZlcnNlZDogInRoZSBkZWNvdXBsaW5nIG9mIHBvbGljeSBm cm9tIHRoZQ0KPiBuZXR3b3JrIHRvcG9sb2d5IiBpcyBhIGdvb2QgdGhpbmcsIHdoaWNoIHdpbGwg YmUgb2J0YWluZWQgYnkgdXNpbmcNCj4gbWV0YWRhdGE7IG9uIHRoZSBjb250cmFyeSwgInRoZSBu ZWVkIGZvciBwZXItc2VydmljZSBmdW5jdGlvbg0KPiBjbGFzc2lmaWNhdGlvbiAoYW5kIHJlLWNs YXNzaWZpY2F0aW9uKSIgaXMgYSBiYWQgdGhpbmcsIG5hbWVseSB0aGUgcHJvYmxlbQ0KPiBtZW50 aW9uZWQgaW4gc2VjdGlvbiAyLjEwLiAgSSB3b3VsZCBwcm9iYWJseSByZXNvbHZlIHRoaXMgd2l0 aCAiWy4uLl0gbW9zdA0KPiBub3RhYmx5IGJ5IGRlY291cGxpbmcgcG9saWN5IGZyb20gdGhlIG5l dHdvcmsgdG9wb2xvZ3ksIGFuZCBieSByZW1vdmluZw0KPiB0aGUgbmVlZCBmb3IgcGVyLXNlcnZp Y2UgZnVuY3Rpb24gY2xhc3NpZmljYXRpb24gKGFuZCByZS1jbGFzc2lmaWNhdGlvbikNCj4gZGVz Y3JpYmVkIGluIHNlY3Rpb24gMi4xMC7igJ0NCg0KUFE+ICBJIGxpa2UgeW91ciBzdWdnZXN0aW9u LCBlYXN5IHRvIGZpeC4NCg0KDQo+IA0KPiBUaGUgYWJzdHJhY3QgdXNlcyB0aGUgcGhyYXNlICJv cmRlcmVkIHNldCBvZiBpbnN0YW5jZXMiLCBidXQgYSBzZXQgaXMNCj4gZXhwbGljaXRseSB1bm9y ZGVyZWQuICBJcyB0aGVyZSBhIGJldHRlciB0ZXJtIHRvIHVzZSwgbGlrZSAiZ3JhcGgiLA0KPiAi bmV0d29yayIsIG9yICJzdHJ1Y3R1cmUiPyAgKFRoZSB3b3JkICJzZXQiIGFsc28gYXBwZWFycyBp biB0aGUgc2Vjb25kDQo+IHBhcmFncmFwaCBvZiB0aGUgYWJzdHJhY3QsIGJ1dCBtYXkgYmUgbW9y ZSBhcHByb3ByaWF0ZSBpbiB0aGF0IHVzYWdlLikNCg0KDQpQUT4gIElzIHRoZXJlIG5vdCBhIGNv bmNlcHQgb2YgYW4gb3JkZXJlZCBzZXQgYXMgd2VsbD8NCg0KPiANCj4gSSdtIG5vdCBzdXJlIEkn bSBpbnRlcnByZXRpbmcgdGhlIHRoaXJkIHBhcmFncmFwaCBvZiBzZWN0aW9uIDIuMSBjb3JyZWN0 bHkNCj4gLS0gaXMgdGhlIGlzc3VlIHRoYXQgdGhlIG5ldHdvcmsgdG9wb2xvZ3kgbmVlZHMgdG8g Y2hhbmdlIGluIGZyb250IGFuZA0KPiBiZWhpbmQgb2YgZWFjaCBzZXJ2aWNlIGZ1bmN0aW9uLCB3 aGVuZXZlciBhIG5ldyBzZXJ2aWNlIGZ1bmN0aW9uIGlzDQo+IHJlcXVpcmVkPyAgT3IgaXMgaXQg dGhhdCB0aGUgbmV0d29yayB0b3BvbG9neSBtdXN0IGNoYW5nZSBiZWZvcmUgYW5kIGFmdGVyDQo+ IGEgbmV3IHNlcnZpY2UgZnVuY3Rpb24gaXMgaW50cm9kdWNlZCwgaW4gb3JkZXIgdG8gYWxsb3cg aW5zZXJ0aW5nIHRoZQ0KPiBmdW5jdGlvbiB3aXRob3V0IGxvc3Mgb2Ygc2VyaWNlPyAgSSB3b3Vs ZCBhbHNvIGZpbmQgdGhlIGxhc3Qgc2VudGVuY2UgbW9yZQ0KPiBjbGVhciBpZiByZW9yZGVyZCB0 byBiZSAiWy4uLl0gYWxsIHRyYWZmaWMgb2Z0ZW4gcGFzc2VzIHRocm91Z2ggdGhlIHNhbWUNCj4g c3RyaWN0IG9yZGVyLCB3aGV0aGVyIGEgZ2l2ZW4gc2VydmljZSBuZWVkcyB0byBiZSBhcHBsaWVk IG9yIG5vdC7igJ0NCg0KUFE+ICBJbiBtYW55IGNhc2VzLCBib3RoLiAgQnV0IHRoZSBpbnRlbnQg aGVyZSBpcyB0byBkZXNjcmliZSB0aGUg4oCcZnJvbnTigJ0gYW5kIOKAnGJlaGluZOKAnSBpc3N1 ZS4NCg0KDQo+IA0KPiBJbiBzZWN0aW9uIDIuMywgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgImNv bnN0cmFpbmVkIHNlcnZpY2UgZnVuY3Rpb24gaGlnaA0KPiBhdmFpbGFiaWxpdHkiIGlzLiAgSXMg dGhlIGlzc3VlIGp1c3QgdGhhdCB0aGUgdG9wb2xvZ3kgZm9yY2VzIGEgc2l0dWF0aW9uDQo+IHdo aWNoIGNvdWxkIGJlIHN1YmplY3QgdG8gcmVkdWNlZCBhdmFpbGFiaWxpdHkgYmVjYXVzZSBjZXJ0 YWluDQo+IGhpZ2gtYXZhaWxhYmlsaXR5IHRlY2huaXF1ZXMgYXJlIG5vdCB1c2FibGUgaW4gdGhh dCB0b3BvbG9neT8NCg0KUFE+ICBDb3JyZWN0LCBhcyBkZXNjcmliZWQgaW4gdGhlIG5leHQgcGFy YWdyYXBoOg0KDQoiU2luY2UgdHJhZmZpYyByZWFjaGVzIG1hbnkgc2VydmljZSBmdW5jdGlvbnMg YmFzZWQgb24gbmV0d29yaw0KICAgdG9wb2xvZ3ksIGFsdGVybmF0ZSwgb3IgcmVkdW5kYW50IHNl cnZpY2UgZnVuY3Rpb25zIG11c3QgYmUgcGxhY2VkIGluDQogICB0aGUgc2FtZSB0b3BvbG9neSBh cyB0aGUgcHJpbWFyeSBzZXJ2aWNlLiINCg0KDQo+IA0KPiBUaGUgcGFyZW50aGV0aWNhbCBpbiB0 aGUgYWJzdHJhY3QgInN1Y2ggYXMgZmlyZXdhbGxzLCBsb2FkIGJhbGFuY2VycyIgaXMNCj4gaW5j b3JyZWN0IGNvbW1hIHVzYWdlOyBJIHdvdWxkIHRhY2sgb24gYSAiLCBldGMuIiBhdCB0aGUgZW5k Lg0KPiANCg0KUFE+ICBHb29kIGNhdGNoLCB0aGFuayB5b3UuDQoNCg0KPiBUaGUgc2Vjb25kIHBh cmFncmFwaCBvZiB0aGUgYWJzdHJhY3QgaXMgaGFyZCB0byBwYXJzZTsgbXkgYmVzdCBlZmZvcnQg YXQNCj4gY2xlYW5pbmcgaXQgdXAgaXMgIlRoZSBzZXQgb2YgZW5hYmxlZCBzZXJ2aWNlIGZ1bmN0 aW9uIGNoYWlucyByZWZsZWN0cyB0aGUNCj4gc2VydmljZSBvZmZlcmluZ3Mgb2YgYSBnaXZlbiBv cGVyYXRvciwgYW5kIGlzIGRlc2lnbmVkIGluIGNvbmp1bmN0aW9uIHdpdGgNCj4gYXBwbGljYXRp b24gZGVsaXZlcnksIHNlcnZpY2UsIGFuZCBuZXR3b3JrIHBvbGljeS4iLCBidXQgSSBmZWFyIHRo YXQgaGFzDQo+IGNoYW5nZWQgdGhlIG1lYW5pbmcgc29tZWhvdy4gICgiY2hhaW5zIiBuZWVkcyB0 byBiZSBwbHVyYWwsIGFzIGRvZXMNCj4gInJlZmxlY3RzIiwgYnV0IHRoZXJlJ3MgYWxzbyBhIG1p c3NpbmcgYXJ0aWNsZSBmb3IgIm9wZXJhdG9yIHNlcnZpY2UNCj4gb2ZmZXJpbmdzIiwgYW5kIHRo ZSB0d28gImFuZHMiIGluIHRoZSBmaW5hbCBjbGF1c2UgcmVhZCBvZGRseS4pDQoNCg0KUFE+ICBJ 4oCZbSBub3Qgc3VyZSB3aGF0IGlzIGhhcmQgdG8gcGFyc2UsIGl0IHNlZW1lZCB3ZWxsIHVuZGVy c3Rvb2QgYnkgdGhlIFdHIG1lbWJlcnMuDQoNCg0KPiANCj4gRmlyc3QgcGFyYWdyYXBoIG9mIHNl Y3Rpb24gMSwgInJlcXVpcmVzIiBzaG91bGQgYmUgcGx1cmFsLiAgKENvbW1hIGFmdGVyDQo+ICJm dW5jdGlvbnMiIGlzIG9wdGlvbmFsLCBidXQgbWlnaHQgaGVscCByZWFkYWJpbGl0eS4pDQoNClBR PiAgVGhhbmsgeW91Lg0KDQoNCj4gDQo+IFNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxLCAi dGhlIG5ldHdvcmsgdG9wb2xvZ3kiIHdpdGggdGhlIGRlZmluaXRlDQo+IGFydGljbGUuICBBbHNv IGFkZCBhIGNvbW1hIGFmdGVyICJsaW1pdHMiIHNvIHRoZSBwYXJlbnRoZXRpY2FsIHN0YXRlbWVu dA0KPiBpcyBwcm9wZXJseSBvZmZzZXQgYnkgY29tbWFzLg0KPiANCj4gVGhlIGRlZmluaXRpb24g Zm9yICJjbGFzc2lmaWNhdGlvbiIgZG9lc24ndCBzZWVtIGdyYW1tYXRpY2FsLiAgUGVyaGFwcywN Cj4gIkxvY2FsbHkgaW5zdGFudGlhdGVkIHBvbGljeSB0byBtYXRjaCB0cmFmZmljIGZsb3dzIHRv IHRoZSBhcHByb3ByaWF0ZQ0KPiBvdXRib3VuZCBhY3Rpb24ocykiPyAgQWRkaXRpb25hbGx5LCBz aG91bGQgdGhlIGRlZmluaXRpb24gYmUgZXhwbGljaXRseQ0KPiBjb25zdHJhaW5lZCB0byBqdXN0 IGZvcndhcmRpbmcgYWN0aW9ucyAobXkgcHJvcG9zYWwgaXMgbm90KT8NCg0KUFE+ICBUaGlzIGlz IHRoZSBkZWZpbml0aW9uIHRoYXQgV0cgY29tZSB1cCB3aXRoIGFmdGVyIHNldmVyYWwgcm91bmRz IG9mZiBiYWNrIGFuZCBmb3J0aCAoaXTigJlzIHVzZWQgaW4gb3RoZXIgU0ZDIGRyYWZ0cykuICBX ZSB0cmllZCB0byBrZWVwIGl0IGdlbmVyaWMsIHJhdGhlciB0aGFuIGNvbnN0cmFpbmVkLiAgDQoN Cg0KPiANCj4gSW4gdGhlIGRlZmluaXRpb24gZm9yICJzZXJ2aWNlIGZ1bmN0aW9uIiwgaXMgIk9u ZSBvZiIgbmVlZGVkPyAgQWxzbywNCj4gcy90aGUgU2VydmljZSBGdW5jdGlvbi9hIFNlcnZpY2Ug RnVuY3Rpb24vIGluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZQ0KPiBmaXJzdCBwYXJhZ3JhcGgu ICBJbiB0aGUgc2Vjb25kIHBhcmFncmFwaCwgdGhlcmUncyBubyBuZWVkIHRvIHNheSAiZXRjLiIN Cj4gd2hlbiBwcmVmYWNlZCB3aXRoICJpbmNsdWRlczoiIC0tIGp1c3Qgc2F5ICJhbmQgVENQIG9w dGltaXphdGlvbiIgKG5vdGUNCj4gcy9vcHRpbWl6ZXIvb3B0aW1pemF0aW9uLyBmb3IgdGVuc2Ug Y29uc2lzdGVuY3kpLg0KDQpQUT4gRGlkIHlvdSBtZWFuIOKAnE9uZSBvcuKAnT8gIElmIHNvLCB0 aGVuIHllcy4gIA0KDQoNCj4gDQo+IFRoZSBkZWZpbml0aW9uIGZvciAiU2VydmljZSBGdW5jdGlv biBDaGFpbiIgaXMgLi4uIG9kZC4gIEkgYmVsaWV2ZSB0aGF0DQo+ICJ0aGVpciBvcmRlcmluZyBy ZXF1aXJlbWVudHMiIHJlZmVycyB0byB0aGUgb3JkZXJpbmcgb2Ygc2VydmljZSBmdW5jdGlvbnMN Cj4gd2l0aGluIHRoZSBjaGFpbiwgYnV0ICJ0aGVpciBvcmRlcmluZyByZXF1aXJlbWVudHMgdGhh dCBtdXN0IGJlIGFwcGxpZWQgdG8NCj4gcGFja2V0cyIgYWN0dWFsbHkgcmVhZHMgdGhhdCB0aGUg b3JkZXJpbmcgcmVxdWlyZW1lbnRzIGNvbWUgZnJvbSB0aGUgc2V0DQo+IG9mIHNlcnZpY2UgZnVu Y3Rpb25zIGJ1dCBpcyBhcHBsaWVkIHRvIHRoZSBwYWNrZXRzIGFuZC9vciBmcmFtZXMuICBJIHdv dWxkDQo+IHByb2JhYmx5IHRyeSB0byBpbnN0ZWFkIHNheSBzb21ldGhpbmcgYWJvdXQgInRoZSBj b25zdHJhaW50cyBvbiB0aGUgb3JkZXINCj4gaW4gd2hpY2ggc2VydmljZSBmdW5jdGlvbnMgYXJl IGFwcGxpZWQgdG8gcGFja2V0cyBhbmQvb3IgZnJhbWVzIi4NCj4gQWRkaXRpb25hbGx5LCAibGlu ZWFyIHByb2dyZXNzaW9uIiBpcyBhIGJpdCB2YWd1ZTsgaXMgdGhlIGludGVudGlvbiBqdXN0DQo+ IHRvIHNheSB0aGF0IGl0IG1heSBhbGxvdyBicmFuY2hpbmcgYW5kIG5lZWQgbm90IGJlIGEgY29t cGxldGUvc3RyaWN0DQo+IG9yZGVyaW5nIChpLmUuLCBpdCBjb3VsZCBiZSBhIHBhcnRpYWwgb3Jk ZXIpPw0KDQpQUT4gIFRoaXMgb2RkbmVzcyBjYW4gYmUgcXVpY2tseSByZXNvbHZlZCBJIHRoaW5r Og0KDQpBIHNlcnZpY2UgRnVuY3Rpb24gY2hhaW4gZGVmaW5lcyBhbiBhYnN0cmFjdCBzZXQgb2Yg c2VydmljZSBmdW5jdGlvbnMgYW5kIGFzc29jaWF0ZWQgb3JkZXJpbmcgY29uc3RyYWludHMNCiAg ICAgIHRoYXQgbXVzdCBiZSBhcHBsaWVkIHRvIHBhY2tldHMgYW5kL29yIGZyYW1lcyBzZWxlY3Rl ZCBhcyBhIHJlc3VsdA0KICAgICAgb2YgY2xhc3NpZmljYXRpb24uIA0KDQpBcyBmb3IgdGhlIGxp bmVhciBzZW50ZW5jZSwgeWVzLCBpdCBpcyB0byBzaW1wbHkgY29udmV5IHRoYXQgdGhlcmUgbWF5 YmUgYSBub24tbGluZWFyIHNlcXVlbmNlIG9mIGZ1bmN0aW9ucy4NCg0KDQo+IA0KPiBJbiB0aGUg ZGVmaW5pdGlvbiBmb3IgIlNlcnZpY2UgVG9wb2xvZ3kiLCB0aGUgcGhyYXNlICJzZXJ2aWNlIG92 ZXJsYXkNCj4gY29ubmVjdGl2aXR5IiBpcyBhIGxpdHRsZSBvZGQ7IEkgbWlnaHQgcmV3b3JkIHRv ICJjb25uZWN0aXZpdHkgb2YgdGhlDQo+IHNlcnZpY2Ugb3ZlcmxheSIuDQo+IA0KPiBJbiBzZWN0 aW9uIDIuMSwgcmVtb3ZlIHRoZSAidGhlIiBmcm9tIGJvdGggInRoZSBzZXJ2aWNlIGRlbGl2ZXJ5 IiBhbmQgInRoZQ0KPiBmbGV4aWJpbGl0eeKAnS4NCg0KUFE+ICBXaWxsIHVwZGF0ZS4NCg0KDQo+ IA0KPiBJbiB0aGUgZm91cnRoIHBhcmFncmFwaCBvZiBzZWN0aW9uIDIuMSwgSSdtIGZhaWxpbmcg dG8gaW50ZXJwcmV0IHRoZQ0KPiBwaHJhc2UgInBsYWNlbWVudCBhbmQgc2VydmljZSBmdW5jdGlv biBzZWxlY3Rpb24gdGFraW5nIGludG8gYWNjb3VudA0KPiBuZXR3b3JrIHRvcG9sb2d5IGluZm9y bWF0aW9uIGlzIG5vdCB2aWFibGUuIiAgSXMgaXQgYWRkaW5nIGFueXRoaW5nIHRoYXQNCj4gaXMg bm90IHNhaWQgcHJpb3IgdG8gdGhlIGNvbG9uIGluIHRoYXQgc2VudGVuY2U/DQoNClBRPiAgVGhl cmUgaXMgc29tZSByZWR1bmRhbmN5IHRoZXJlIHRoYXQgY2FuIGJlIGNsZWFuZWQgdXAuDQoNCg0K PiANCj4gSW4gdGhlIGZpZnRoIHBhcmFncmFwaCBvZiBzZWN0aW9uIDIuMSwgYWRkIGEgY29tbWEg YmVmb3JlICJmb3JjaW5nIiwgdG8NCj4gc2VwYXJhdGUgdGhlIGluZGVwZW5kZW50IGFuZCBkZXBl bmRlbnQgY2xhdXNlcy4NCj4gDQo+IEluIHNlY3Rpb24gMi4yLCBpcyAib25jZSBpbnN0YWxsZWQs IGNvbmZpZ3VyZWQgYW5kIGRlcGxveWVkIGluIHByb2R1Y3Rpb24NCj4gZW52aXJvbm1lbnRzIiBu ZWVkZWQ/ICBJIG1pZ2h0IGFkZCAidGhlIiBiZWZvcmUgInVzZSIgaW4gdGhlIGxhc3QgbGluZSB0 bw0KPiBhaWQgcmVhZGFiaWxpdHksIGJ1dCBpdCBpcyBwcm9iYWJseSBub3Qgc3RyaWN0bHkgbmVj ZXNzYXJ5IGZvcg0KPiBjb3JyZWN0bmVzcy4NCj4gDQo+IEluIHRoZSBzZWNvbmQgcGFyYWdyYXBo IG9mIHNlY3Rpb24gMi4zLCBhZGQgInRoZSIgYmVmb3JlICJuZXR3b3JrIiwgYW5kDQo+IGNvbnNp ZGVyIHJlbW92aW5nIHRoZSBjb21tYSBhZnRlciAiYWx0ZXJuYXRl4oCdLg0KPiANCj4gSW4gc2Vj dGlvbiAyLjUsIHJlbW92ZSB0aGUgc3BhY2UgaW4gIihyZSkgY2xhc3NpZmljYXRpb24iLiAgVXNl IGEgY29tbWENCj4gYWZ0ZXIgImkuZS4iIGFzIHdlbGwgYXMgYmVmb3JlLiAgImluY3JlYXNpbmds eSBsZXNzIiBpcyBzdHJhbmdlIHVzYWdlOw0KPiBjb25zaWRlciBqdXN0ICJkZWNyZWFzaW5nbHki LiAgVXNlICJ0b3BvbG9neSBpbmZvcm1hdGlvbiIgY29uc2lzdGVudGx5DQo+IChub3QgInRvcG9s b2dpY2FsIGluZm9ybWF0aW9uIikuICBVc2UgYSBjb21tYSBhZnRlciB0aGUgc2VudGVuY2UgYWR2 ZXJiDQo+ICJmdXJ0aGVybW9yZSIuDQo+IA0KDQpQUT4gIFdpbGwgdXBkYXRlLg0KDQoNCj4gSW4g c2VjdGlvbiAyLjYsIGFkZCAibmV0d29yayIgYmVmb3JlICJ1bmRlciBhbmQgb3ZlcmxheXMiIChv ciBtZW50aW9uIHRoYXQNCj4ganVzdCAib3ZlcmxheXMiIGlzIHZhbGlkIHVzYWdlIGluIHRoZSBk ZWZpbml0aW9uIGluIHNlY3Rpb24gMS4xKS4NCj4gDQo+IEluIHNlY3Rpb24gMi43LCBhcmUgInN1 Y2ggY2hhbmdlIiB0aGUgVkxBTiBjaGFuZ2VzIG9yIHRoZSBzZXJ2aWNlDQo+IGRlcGxveW1lbnQg Y2hhbmdlcz8gIFRoZSBjdXJyZW50IHRleHQgaGFzICJzdWNoIGNoYW5nZXMiIGJpbmQgdG8gImNo YW5nZXMNCj4gdG8gdGhlIHNlcnZpY2UgZGVwbG95bWVudCIsIG1ha2luZyB0aGUgY2xhdXNlIHRh dXRvbG9naWNhbC4NCg0KUFE+ICBCb3RoIGVhc3kgZml4ZXMuDQoNCj4gDQo+IEluIHNlY3Rpb24g Mi44LCAidHJhZmZpYyIgaXMgc2luZ3VsYXIsIHNvICJ0cmF2ZXJzZXMiIHRvIG1hdGNoIChmaXJz dA0KPiBzZW50ZW5jZSkuICBDb25zaWRlciBleHBhbmRpbmcgdG8gImFsbCBzZXJ2aWNlIGZ1bmN0 aW9ucyBvbiB0aGF0IHNlZ21lbnQiDQo+IGFzIHdlbGwsIGZvciBjbGFyaXR5LiAgQWxzbyBjb25z aWRlciBhZGRpbmcgIndoaWNoIiBhZnRlciAiZGF0YQ0KPiB0cmF2ZXJzZXMiLg0KPiANCj4gSW4g c2VjdGlvbiAyLjEwLCBjb25zaWRlciAiYmV0d2VlbiBzZXJ2aWNlIGZ1bmN0aW9ucyIgaW5zdGVh ZCBvZiAicGVyDQo+IHNlcnZpY2UgZnVuY3Rpb24iLCBidXQgaW4gZWl0aGVyIGNhc2UgYWRkIGEg Y29tbWEgYWZ0ZXJ3YXJkLiAgSSB3b3VsZCBhbHNvDQo+IGNsYXJpZnkgYnkgYWRkaW5nICJjbGFz c2lmaWNhdGlvbiIgaW4gInRoZSByZXN1bHRzIGZyb20gb3RoZXIgc2VydmljZQ0KPiBmdW5jdGlv bnMiLg0KPiANCj4gSW4gc2VjdGlvbiAyLjExLCBjb21tYSBhZnRlciAiYXNzb2NpYXRpb24iIHRv IHNlcGFyYXRlIHRoZSBkZXBlbmRlbnQgYW5kDQo+IGluZGVwZW5kZW50IGNsYXVzZXMuICAoQWxz bywgc2hvdWxkIGl0IGJlIHRoZSBwbHVyYWwgImFzc29jaWF0aW9ucyI/KQ0KPiANCj4gSW4gc2Vj dGlvbiAzLjEsIHRoZSB0d28gImFuZCJzIGlzIHVuY29tbW9uIHVzYWdlLiAgTW9zdCBzdWNoIGNh c2VzIHdvdWxkDQo+IGJlIGNvbmRlbnNlZCB0byBhIGNvbW1hLXNlcGFyYXRlZCBsaXN0LCBidXQg aGVyZSBJIHdvdWxkIHJlY29tbWVuZCAiIiJUaGUNCj4gc2VydmljZSBvdmVybGF5IHByb3ZpZGVz IHNlcnZpY2UgZnVuY3Rpb24gY29ubmVjdGl2aXR5LCBidWlsZGluZyAib24NCj4gdG9wIiBvZiB0 aGUgZXhpc3RpbmcgbmV0d29yayB0b3BvbG9neSB0byBhbGxvdyBvcGVyYXRvcnMgdG8gdXNlIHdo YXRldmVyDQo+IG92ZXJsYXkgb3IgdW5kZXJsYXkgdGhleSBwcmVmZXIgZm9yIGNyZWF0aW5nIGEg cGF0aCBiZXR3ZWVuIHNlcnZpY2UNCj4gZnVuY3Rpb25zLCBhbmQgdG8gbG9jYXRlIHNlcnZpY2Ug ZnVuY3Rpb25zIGluIHRoZSBuZXR3b3JrIGFzIG5lZWRlZC4iIiINCj4gDQo+IEluIHRoZSBsYXN0 IHBhcmFncmFwaCBvZiBzZWN0aW9uIDMuMSwgaHlwaGVuYXRlICJzZXJ2aWNlLXNwZWNpZmljDQo+ IGluZm9ybWF0aW9uIi4NCj4gDQo+IEluIHNlY3Rpb24gMy4yLCByZXBsYWNlICJzZXJ2aWNlIG9m ZmVyZWQiIHdpdGggInRoZSBzZXJ2aWNlcyBvZmZlcmVkIi4NCj4gDQo+IFNlY3Rpb24gMy4zIGlz IGluY29uc2lzdGVudCBhYm91dCB0aGUgd2hpdGVzcGFjZSBpbiAiZGF0YXBsYW5lIiBiZXR3ZWVu DQo+IHNlY3Rpb24gdGl0bGUgYW5kIGJvZHkuDQo+IA0KPiBUaGUgc2Vjb25kIHNlbnRlbmNlIG9m IHNlY3Rpb24gNCBoYXMgd2hhdCBpcyBiYXNpY2FsbHkgYSBjb21tYSBzcGxpY2U7IEkNCj4gd291 bGQgZml4IGl0IGJ5ICJbLi4uXSBleGhhdXN0aXZlOyByYXRoZXIsIGl0IFsuLi5d4oCdLg0KDQpQ UT4gIFdl4oCZbGwgZ28gdGhyb3VnaCB0aGUgY29ycmVjdGlvbnMgYWJvdmUgYW5kIGNsZWFuIHRo aW5ncyBhcyBuZWVkZWQuDQoNCg0KPiANCj4gVGhlIGVudW1lcmF0ZWQgZW50cmllcyBpbiBzZWN0 aW9uIDQgYXJlIGluY29uc2lzdGVudCBhYm91dCB3aGV0aGVyIHRoZQ0KPiB3b3JraW5nIGdyb3Vw IG5hbWUgaXMgZXhwYW5kZWQgaW4gdGhlIGJvZHkgdGV4dCwgYW5kIGV2ZW4gd2hldGhlciBpdCBp cw0KPiByZWZlcnJlZCB0byBhcyBhIHdvcmtpbmcgZ3JvdXAgKG9yIGp1c3QgYSBwcm9wZXIgbm91 biBpbiBpdHMgb3duIHJpZ2h0LA0KPiB2aXouICJMSVNQIikuDQo+IA0KPiBJbiBzZWN0aW9uIDQs IGl0ZW0gMywgYWRkICJUaGUiIGJlZm9yZSAiTlZPMyBXRyIuDQo+IA0KPiANCj4gDQo+IC1CZW4g S2FkdWsNCg0K From nobody Tue Jan 13 09:27:20 2015 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 D271B1A8BB2; Tue, 13 Jan 2015 09:27:17 -0800 (PST) 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 j2ZSRWcKwk3G; Tue, 13 Jan 2015 09:27:14 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7504A1A8FD7; Tue, 13 Jan 2015 09:27:12 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id u20so3360976oif.7; Tue, 13 Jan 2015 09:27:11 -0800 (PST) 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=OyAoOByTxZT41AIgYy1RUj6/w61PgnUxmNtAFty6ejs=; b=oSg3/3xr0+lp0YYMbT9p9iaC9SpKDoPq9fr9MJt412OhYTyUTM6DwQF9dw+nRhF4TI mozHgLOfHzOnwy5a3rEiFGtcOllTW3KE09getciuo3YmhX0QU909pGHHibfj9ixJS20k ZR8Bs1LuKV4Rn9PLgiOZNRTwVUg5YIaB4fEWBM6mqyrIqZqm4Y6ptUl+4TX5Rt7E9qel sxafTWdVdZ1NW/K51lx95WI6kU99EcBNOgMTA1P6Y5SvN3iJlgQzeexYlhlLWHB5vWho /T13msaLM8/vLjWA1X3VEXaH7Xh0itX9UicOmWwD+MAt7PoBZtP/tWKSz0e2+yCB5rYc jdCg== X-Received: by 10.60.133.141 with SMTP id pc13mr21789152oeb.68.1421170031735; Tue, 13 Jan 2015 09:27:11 -0800 (PST) Received: from ?IPv6:2602:306:3406:4f00:f929:6fd:8d3d:951a? ([2602:306:3406:4f00:f929:6fd:8d3d:951a]) by mx.google.com with ESMTPSA id si7sm10856185obc.20.2015.01.13.09.27.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 09:27:10 -0800 (PST) From: "Adam W. Montville" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com> Date: Tue, 13 Jan 2015 11:26:33 -0600 To: The IESG , secdir@ietf.org, draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [secdir] SecDir review of draft-ietf-ospf-ospfv3-autoconfig 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, 13 Jan 2015 17:27:18 -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 draft is ready with comments/nits. Comments The document describes necessary mechanisms for OSPFv3 to be = self-configuring in environments requiring such (e.g. IPv6 home = networks). A couple of things stood out to me. First, I inferred from the document = that the uniqueness of Router IDs is so within the context of the = present deployment and not, for example, unique between domains. This = may be common knowledge in the world of OSPF, but wasn=E2=80=99t to me = (at least not initially). It could be good to add a sentence about the = context of Router ID uniqueness early on in the document. Also regarding uniqueness of the ID, Section 5, =E2=80=9COSPFv3 Router = ID Selection=E2=80=9D, indicates that a pseudo-random number SHOULD be = used to derive the Router ID. Later in that first paragraph: =E2=80=9CThe= generation should be seeded with a variable that is likely to be unique = in the applicable OSPFv3 router deployment.=E2=80=9D Should that = =E2=80=9Cshould=E2=80=9D be =E2=80=9CSHOULD=E2=80=9D? The document clearly recognizes the possibility for Router ID = collisions, and there does not appear to be a need for a = cryptographically sound pseudo-random number generation - just enough = entropy to make the Router ID unique within the deployment domain, and = the Router-Hardware-Fingerprint TLV (Section 7.2.2) is presented as = being enough. Because this document essentially explains the OSPFv3 defaults a router = should have in order to support auto-configuration, I presumed that the = security considerations provided in previous OSPFv3 documents would = essentially be in effect here. This isn=E2=80=99t explicitly stated in = the Security Considerations section, but could be without harm, should = they apply here. The bottom line for me is that it seems that OSPFv3 = auto-configuration favors usability over security, but without ignoring = security entirely (e.g. =E2=80=9Cauto-configuration can also be combined = with password configuration or future extensions for automatic pairing = between devices.=E2=80=9D).= From nobody Tue Jan 13 12:49:27 2015 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 181541AD061; Tue, 13 Jan 2015 12:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gxpWSkVnOja; Tue, 13 Jan 2015 12:49:21 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179501AD05B; Tue, 13 Jan 2015 12:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3011; q=dns/txt; s=iport; t=1421182161; x=1422391761; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=y69IZIoAK74S+fduFXd47I+CSST1u07uaw0C28sxqGA=; b=aV2Q9GRCuQUdOP7fyco093N5CVjH1T/7tcAFj9wllfqpV2s2po9qEJ0D YMYWGMi0aVER/R2O1CUxKTrZ5s1kcgigiZBAFCxtOWpVcM5gSdZiMl3Bn PUXz4tsKlFn/Vsvjcrj0CM/yRPryZRlg6YwCZbZXLGek+xop6Ak3eaKrU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsGAKeDtVStJA2B/2dsb2JhbABbgwZSWASDAcMPhw5DAQEBAQF9hDYPAUU2AgUWCwILAwIBAgE1FgEMBgIBAYgoDbt3k3cBAQEBAQEEAQEBAQEBGASBIZFHgUEFiWaIIYIGg0KGGotiIoQOT4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,751,1413244800"; d="scan'208";a="112978024" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 13 Jan 2015 20:49:20 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0DKnKGs019249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 20:49:20 GMT Received: from [10.129.24.63] (10.129.24.63) by xhc-aln-x09.cisco.com (173.36.12.83) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 13 Jan 2015 14:49:20 -0600 Message-ID: <54B584CF.2030909@cisco.com> Date: Tue, 13 Jan 2015 13:49:19 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: The IESG , IETF Security Directorate , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.63] Archived-At: Subject: [secdir] secdir review of draft-ietf-opsawg-coman-use-cases-03 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, 13 Jan 2015 20:49:23 -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. SUMMARY: This Informational document describes use cases for managing a network involving constrained devices (e.g., sensors, smart controllers), along with a discussion on network access and the operational lifecycle of such devices. This also covers some situational guidelines and requirements specific to the discussed use cases. This document is ready with nits. My one issue I have might not be appropriate for this use case document, and my other nits are simply editorial. MINOR ISSUE: There is little mention about data protection within this document, but is discussed some in [COM-REQ]. However, neither this document nor [COM-REQ] include any discussion about protecting data as it traverses networks (e.g., using TLS or DTLS), as far as I can tell. I assume this will be covered in greater detail in any Standards Track documents derived from these documents, but might be worthwhile to at least mention in the use cases where in-transit data protection needs special considerations, if not more generally in [COM-REQ]. NITS (not security related): * RFC7228 is listed as informational, but it probably ought to be normative. It seems to me that it's necessary to understand the terms from RFC7228 in order to understand this document. * [COM-REQ] is listed as an informational reference, but ought to be normative. It seems to me that it's necessary to understand [COM-REQ] in order to understand this document, at least from a security perspective. * Throughout the document, the locution "ad-hoc" should be "ad hoc". * Throughout the document, the phrase "In cases" is almost always (two out of three) followed by a comma, which seems superfluous. * In section 1. second paragraph, "type" should be "types" in the phrase "... the management of a network with constrained devices offers different type of challenges compared to ...". * In section 2. last paragraph, "since tend" should be "since they tend" in the phrase "... are not discussed here since tend to be quite static and do not typically impose ..." * In section 4.1. second paragraph, "looses" should be "loses" in the phrase "... new constrained devices in case the system looses too much of its structure." * In section 4.1. second paragraph, "loosing" should be "losing" in the phrase "... deal with events such as loosing neighbors or being moved to other locations." -- - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [COM-REQ] "Management of Networks with Constrained Devices: Problem Statement and Requirements" From nobody Tue Jan 13 13:31:30 2015 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 692EB1AD49D; Tue, 13 Jan 2015 13:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 FtoHmI1kOFPc; Tue, 13 Jan 2015 13:31:22 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07EC1AD481; Tue, 13 Jan 2015 13:31:22 -0800 (PST) Received: from mb-aye.local ([209.49.54.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t0DLVHcb014358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Jan 2015 21:31:17 GMT (envelope-from joelja@bogus.com) Message-ID: <54B58E9E.3060907@bogus.com> Date: Tue, 13 Jan 2015 13:31:10 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= , The IESG , IETF Security Directorate , draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org References: <54B584CF.2030909@cisco.com> In-Reply-To: <54B584CF.2030909@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5GHcGFxdRVqFnaF7RuP0udSm8HgNTe2bR" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-opsawg-coman-use-cases-03 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, 13 Jan 2015 21:31:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5GHcGFxdRVqFnaF7RuP0udSm8HgNTe2bR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Matt! joel On 1/13/15 12:49 PM, =E2=8C=98 Matt Miller 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= =2E > 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 > SUMMARY: >=20 > This Informational document describes use cases for managing a network > involving constrained devices (e.g., sensors, smart controllers), along= > with a discussion on network access and the operational lifecycle of > such devices. This also covers some situational guidelines and > requirements specific to the discussed use cases. >=20 > This document is ready with nits. My one issue I have might not be > appropriate for this use case document, and my other nits are simply > editorial. >=20 >=20 > MINOR ISSUE: >=20 > There is little mention about data protection within this document, but= > is discussed some in [COM-REQ]. However, neither this document nor > [COM-REQ] include any discussion about protecting data as it traverses > networks (e.g., using TLS or DTLS), as far as I can tell. I assume thi= s > will be covered in greater detail in any Standards Track documents > derived from these documents, but might be worthwhile to at least > mention in the use cases where in-transit data protection needs special= > considerations, if not more generally in [COM-REQ]. >=20 >=20 > NITS (not security related): >=20 > * RFC7228 is listed as informational, but it probably ought to be > normative. It seems to me that it's necessary to understand the terms > from RFC7228 in order to understand this document. >=20 > * [COM-REQ] is listed as an informational reference, but ought to be > normative. It seems to me that it's necessary to understand [COM-REQ] > in order to understand this document, at least from a security perspect= ive. >=20 > * Throughout the document, the locution "ad-hoc" should be "ad hoc". >=20 > * Throughout the document, the phrase "In cases" is almost always (two > out of three) followed by a comma, which seems superfluous. >=20 > * In section 1. second paragraph, "type" should be "types" in the phras= e > "... the management of a network with constrained devices offers > different type of challenges compared to ...". >=20 > * In section 2. last paragraph, "since tend" should be "since they tend= " > in the phrase "... are not discussed here since tend to be quite static= > and do not typically impose ..." >=20 > * In section 4.1. second paragraph, "looses" should be "loses" in the > phrase "... new constrained devices in case the system looses too much > of its structure." >=20 > * In section 4.1. second paragraph, "loosing" should be "losing" in the= > phrase "... deal with events such as loosing neighbors or being moved t= o > other locations." >=20 >=20 --5GHcGFxdRVqFnaF7RuP0udSm8HgNTe2bR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlS1jp4ACgkQ8AA1q7Z/VrIQ9gCbBoVdGBAwQRPJAazSd2jt9qUY GiYAoIr2ZVh+Y2zYKQOiFR8+Rni37ZwR =5XAG -----END PGP SIGNATURE----- --5GHcGFxdRVqFnaF7RuP0udSm8HgNTe2bR-- From nobody Tue Jan 13 17:14:26 2015 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 964E31ACE27; Tue, 13 Jan 2015 17:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHPDEV6LW0-O; Tue, 13 Jan 2015 17:14:15 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E3F1ACE20; Tue, 13 Jan 2015 17:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2920; q=dns/txt; s=iport; t=1421198055; x=1422407655; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YXkvA7py98CYKJ0yIeN4QuQy8nPGS65puvipeMATZ/k=; b=Mga/9YfS4tfy2T//sM/UqPx/cL//YLVe4WtYf3qsm3j5xY91/HduJ1MU OLoNo//NKvzkS8Mokz8yjPUwR3+uCZA4ijEhYo1hcrzv2vl2tq7NitQ3Q 372EcnWGJfhnB/rqQvrTcsSxSmAsp0L3pNUk0FC4EcpkrVoRFB4cGZU5p Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAG/CtVStJV2S/2dsb2JhbABbgwaBKgTMCAKBF0MBAQEBAX2EDQEBBIEJAgEIMBYhESUCBAESiBgDEcwRDYNjAQEBAQEBAQMBAQEBAQEBG41PgXc6GIQRBYk8hQaFS4F+gUSMGIVkIoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,753,1413244800"; d="scan'208";a="386734196" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jan 2015 01:14:13 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0E1EDDS005040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Jan 2015 01:14:13 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.144]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 19:14:13 -0600 From: "Acee Lindem (acee)" To: "Adam W. Montville" , The IESG , "secdir@ietf.org" , "draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-ospf-ospfv3-autoconfig Thread-Index: AQHQL1ZN15yQ//E1nEqbwCq7FRW/cZy+4OYA Date: Wed, 14 Jan 2015 01:14:13 +0000 Message-ID: References: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com> In-Reply-To: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9A62A5ECEA8284448FE0C93F5CBB4B23@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-ospf-ospfv3-autoconfig 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, 14 Jan 2015 01:14:17 -0000 Hi Adam,=20 On 1/13/15, 12:26 PM, "Adam W. Montville" 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 draft is ready with comments/nits. > >Comments >The document describes necessary mechanisms for OSPFv3 to be >self-configuring in environments requiring such (e.g. IPv6 home networks). > >A couple of things stood out to me. First, I inferred from the document >that the uniqueness of Router IDs is so within the context of the present >deployment and not, for example, unique between domains. This may be >common knowledge in the world of OSPF, but wasn=B9t to me (at least not >initially). It could be good to add a sentence about the context of >Router ID uniqueness early on in the document. I will add a statement to section 5. > >Also regarding uniqueness of the ID, Section 5, =B3OSPFv3 Router ID >Selection=B2, indicates that a pseudo-random number SHOULD be used to >derive the Router ID. Later in that first paragraph: =B3The generation >should be seeded with a variable that is likely to be unique in the >applicable OSPFv3 router deployment.=B2 Should that =B3should=B2 be =B3SH= OULD=B2? Yes - these two sentences definitely SHOULD be consistent. > >The document clearly recognizes the possibility for Router ID collisions, >and there does not appear to be a need for a cryptographically sound >pseudo-random number generation - just enough entropy to make the Router >ID unique within the deployment domain, and the >Router-Hardware-Fingerprint TLV (Section 7.2.2) is presented as being >enough. Do you feel that a statement with respect to the pseudo-random algorithm is necessary? If so, can you suggest some text? > >Because this document essentially explains the OSPFv3 defaults a router >should have in order to support auto-configuration, I presumed that the >security considerations provided in previous OSPFv3 documents would >essentially be in effect here. This isn=B9t explicitly stated in the >Security Considerations section, but could be without harm, should they >apply here. The bottom line for me is that it seems that OSPFv3 >auto-configuration favors usability over security, but without ignoring >security entirely (e.g. =B3auto-configuration can also be combined with >password configuration or future extensions for automatic pairing between >devices.=B2). I agree with the above except that the document doesn't address all the available OSPFv3 security options. Let me add a paragraph. I will provide some updated text for review prior to republishing. Thanks, Acee=20 From nobody Tue Jan 13 18:08:15 2015 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 14CDF1A8974; Tue, 13 Jan 2015 18:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33dVWqLGYfWE; Tue, 13 Jan 2015 18:07:59 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455D21A8820; Tue, 13 Jan 2015 18:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7888; q=dns/txt; s=iport; t=1421201276; x=1422410876; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2AbeLsCUcODK+QyUKnA6Mo9Vcv/wPgoSPMOUz01KJ/M=; b=gIzk95M2pNTGynWIM91dOmPPqJ9qw253FpzubgfkPNDSyCLjsnrWxd/q 1nIeh3kznPBDzMgG23zwRGSn32u2tRMBpYMA2hJLcU7ti2X9R84nyqVBJ S4ZUo/l069OaERNREfWO0X9W0rNb/4LtzOggPAkjVBHaU43qimDXVkzSm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksIANjOtVStJV2Z/2dsb2JhbABbgwaBKgSDAckLAhx9QwEBAQEBfYQNAQEENFUCAQgcFBQCAh8RJQIEARKIGAMRnnKcYgaQHQ2DYwEBAQEBAQEDAQEBAQEBARuBG4w0gXc6GIJKgUcFjkKFS4F+gUSBD4sJgieDPSKCAR2BUG8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,753,1413244800"; d="scan'208";a="113046695" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 14 Jan 2015 02:07:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0E27tvG000570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Jan 2015 02:07:55 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.144]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 20:07:55 -0600 From: "Acee Lindem (acee)" To: "Adam W. Montville" , The IESG , "secdir@ietf.org" , "draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-ospf-ospfv3-autoconfig Thread-Index: AQHQL1ZN15yQ//E1nEqbwCq7FRW/cZy+4OYAgAAPAIA= Date: Wed, 14 Jan 2015 02:07:54 +0000 Message-ID: References: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="euc-kr" Content-ID: <34722907102AAD46A88F2BD758A37666@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-ospf-ospfv3-autoconfig 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, 14 Jan 2015 02:08:05 -0000 SGkgQWRhbSwgDQpIZXJlIGFyZSB0aGUgdXBkYXRlcyBJoa9tIHByb3Bvc2luZyB0byBhZGRyZXNz IHlvdXIgY29tbWVudHM6DQoNCioqKiAxODAsMTg1ICoqKioNCi0tLSAxODAsMTg4IC0tLS0NCiAg ICAgVGhhbmtzIHRvIE1hcnRpbiBWaWdvdXJldXggZm9yIFJvdXRpbmcgQXJlYSBEaXJlY3RvcmF0 ZSByZXZpZXcgYW5kDQogICAgIGNvbW1lbnRzLg0KICANCisgICAgVGhhbmtzIHRvIEFkYW0gTW9u dHZpbGxlIGZvciBTZWN1cml0eSBBcmVhIERpcmVjdG9yYXRlIHJldmlldyBhbmQNCisgICAgY29t bWVudHMuDQorDQogICAgIFNwZWNpYWwgdGhhbmtzIGdvIHRvIE1hcmt1cyBTdGVuYmVyZyBmb3Ig aGlzIGltcGxlbWVudGF0aW9uIG9mIHRoaXMNCiAgICAgc3BlY2lmaWNhdGlvbiBpbiBCaXJkLg0K ICANCioqKioqKioqKioqKioqKg0KDQoqKiogNDUxLDQ2NCAqKioqDQoNCjUuICBPU1BGdjMgUm91 dGVyIElEIFNlbGVjdGlvbg0KDQohICAgIEFuIE9TUEZ2MyByb3V0ZXIgcmVxdWlyZXMgYSB1bmlx dWUgUm91dGVyIElEIGZvciBjb3JyZWN0IHByb3RvY29sDQohICAgIG9wZXJhdGlvbi4gIEFuIE9T UEZ2MyByb3V0ZXIgaW1wbGVtZW50aW5nIHRoaXMgc3BlY2lmaWNhdGlvbiB3aWxsDQohICAgIHNl bGVjdCBhIHJvdXRlci1pZCB0aGF0IGhhcyBhIGhpZ2ggcHJvYmFiaWxpdHkgb2YgdW5pcXVlbmVz cy4gIEENCiEgICAgcHNldWRvLXJhbmRvbSBudW1iZXIgU0hPVUxEIGJlIHVzZWQgZm9yIHRoZSBP U1BGdjMgUm91dGVyIElELiAgVGhlDQohICAgIGdlbmVyYXRpb24gc2hvdWxkIGJlIHNlZWRlZCB3 aXRoIGEgdmFyaWFibGUgdGhhdCBpcyBsaWtlbHkgdG8gYmUNCiEgICAgdW5pcXVlIGluIHRoZSBh cHBsaWNhYmxlIE9TUEZ2MyByb3V0ZXIgZGVwbG95bWVudC4gIEEgZ29vZCBjaG9pY2Ugb2YNCiEg ICAgc2VlZCB3b3VsZCBiZSBzb21lIHBvcnRpb24gb3IgaGFzaCBvZiB0aGUgUm91dGVyLUhhcmR3 YXJlLUZpbmdlcnByaW50DQohICAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMi4yLg0KDQog ICAgU2luY2UgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSBvZiBhIFJvdXRlciBJRCBjb2xsaXNpb24s IGR1cGxpY2F0ZQ0KICAgIFJvdXRlciBJRCBkZXRlY3Rpb24gYW5kIHJlc29sdXRpb24gYXJlIHJl cXVpcmVkIGFzIGRlc2NyaWJlZCBpbg0KLS0tIDQ1MSw0NjUgLS0tLQ0KDQo1LiAgT1NQRnYzIFJv dXRlciBJRCBTZWxlY3Rpb24NCg0KISAgICBBbiBPU1BGdjMgcm91dGVyIHJlcXVpcmVzIGEgdW5p cXVlIFJvdXRlciBJRCB3aXRoaW4gdGhlIE9TUEZ2Mw0KISAgICByb3V0aW5nIGRvbWFpbiBmb3Ig Y29ycmVjdCBwcm90b2NvbCBvcGVyYXRpb24uICBBbiBPU1BGdjMgcm91dGVyDQohICAgIGltcGxl bWVudGluZyB0aGlzIHNwZWNpZmljYXRpb24gd2lsbCBzZWxlY3QgYSByb3V0ZXItaWQgdGhhdCBo YXMgYQ0KISAgICBoaWdoIHByb2JhYmlsaXR5IG9mIHVuaXF1ZW5lc3MuICBBIHBzZXVkby1yYW5k b20gbnVtYmVyIFNIT1VMRCBiZQ0KISAgICB1c2VkIGZvciB0aGUgT1NQRnYzIFJvdXRlciBJRC4g IFRoZSBnZW5lcmF0aW9uIFNIT1VMRCBiZSBzZWVkZWQgd2l0aA0KISAgICBhIHZhcmlhYmxlIHRo YXQgaXMgbGlrZWx5IHRvIGJlIHVuaXF1ZSBpbiB0aGUgYXBwbGljYWJsZSBPU1BGdjMNCiEgICAg cm91dGVyIGRlcGxveW1lbnQuICBBIGdvb2QgY2hvaWNlIG9mIHNlZWQgd291bGQgYmUgc29tZSBw b3J0aW9uIG9yDQohICAgIGhhc2ggb2YgdGhlIFJvdXRlci1IYXJkd2FyZS1GaW5nZXJwcmludCBh cyBkZXNjcmliZWQgaW4NCiEgICAgU2VjdGlvbiA3LjIuMi4NCg0KICAgIFNpbmNlIHRoZXJlIGlz IGEgcG9zc2liaWxpdHkgb2YgYSBSb3V0ZXIgSUQgY29sbGlzaW9uLCBkdXBsaWNhdGUNCiAgICBS b3V0ZXIgSUQgZGV0ZWN0aW9uIGFuZCByZXNvbHV0aW9uIGFyZSByZXF1aXJlZCBhcyBkZXNjcmli ZWQgaW4NCioqKioqKioqKioqKioqKg0KDQoqKiogNzk5LDgxMCAqKioqDQogICAgYXV0b21hdGlj IHBhaXJpbmcgYmV0d2VlbiBkZXZpY2VzLiAgVGhlc2UgbWVjaGFuaXNtcyBjYW4gaGVscCBwcm92 aWRlDQogICAgYW4gYXV0b21hdGljYWxseSBjb25maWd1cmVkLCBzZWN1cmVseSByb3V0ZWQgbmV0 d29yay4NCg0KIQ0KIQ0KIQ0KIQ0KIQ0KIQ0KDQoNCg0KLS0tIDc5OSw4MTAgLS0tLQ0KICAgIGF1 dG9tYXRpYyBwYWlyaW5nIGJldHdlZW4gZGV2aWNlcy4gIFRoZXNlIG1lY2hhbmlzbXMgY2FuIGhl bHAgcHJvdmlkZQ0KICAgIGFuIGF1dG9tYXRpY2FsbHkgY29uZmlndXJlZCwgc2VjdXJlbHkgcm91 dGVkIG5ldHdvcmsuDQoNCiEgICAgSW4gZGVwbG95bWVudHMgd2hlcmUgc3Ryb25nZXIgYXV0aGVu dGlmaWNhdGlvbiBvciBlbmNyeXB0aW9uIGlzDQohICAgIHJlcXVpcmVkLCBPU1BGdjMgSVBzZWMg W09TUEZWMy1JUFNFQ10gb3Igc3Ryb25nZXIgT1NQRnYzDQohICAgIEF1dGhlbnRpY2F0aW9uIHRy YWlsZXIgW09TUEZWMy1BVVRILVRSQUlMRVJdIGFsZ29yaXRobXMgTUFZIGJlIHVzZWQNCiEgICAg YXQgdGhlIGV4cGVuc2Ugb2YgYWRkaXRpb25hbCBjb25maWd1cmF0aW9uLiAgVGhlIGNvbmZpZ3Vy YXRpb24gYW5kDQohICAgIG9wZXJhdGlvbmFsIGRlc2NyaXB0aW9uIG9mIHN1Y2ggZGVwbG95bWVu dHMgaXMgYmV5b25kIHRoZSBzY29wZSBvZg0KISAgICB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KKioq KioqKioqKioqKioqDQoNCg0KVGhhbmtzLA0KQWNlZSANCg0KT24gMS8xMy8xNSwgODoxNCBQTSwg IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCg0KPkhpIEFkYW0s IA0KPg0KPk9uIDEvMTMvMTUsIDEyOjI2IFBNLCAiQWRhbSBXLiBNb250dmlsbGUiIDxhZGFtLncu bW9udHZpbGxlQGdtYWlsLmNvbT4NCj53cm90ZToNCj4NCj4+SSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPj5vbmdvaW5n IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0 aGUgSUVTRy4NCj4+VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhl IGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5DQo+PmFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlDQo+PmNvbW1lbnRzIGp1c3QgbGlr ZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPj4NCj4+VGhpcyBkcmFmdCBpcyByZWFk eSB3aXRoIGNvbW1lbnRzL25pdHMuDQo+Pg0KPj5Db21tZW50cw0KPj5UaGUgZG9jdW1lbnQgZGVz Y3JpYmVzIG5lY2Vzc2FyeSBtZWNoYW5pc21zIGZvciBPU1BGdjMgdG8gYmUNCj4+c2VsZi1jb25m aWd1cmluZyBpbiBlbnZpcm9ubWVudHMgcmVxdWlyaW5nIHN1Y2ggKGUuZy4gSVB2NiBob21lDQo+ Pm5ldHdvcmtzKS4NCj4+DQo+PkEgY291cGxlIG9mIHRoaW5ncyBzdG9vZCBvdXQgdG8gbWUuICBG aXJzdCwgSSBpbmZlcnJlZCBmcm9tIHRoZSBkb2N1bWVudA0KPj50aGF0IHRoZSB1bmlxdWVuZXNz IG9mIFJvdXRlciBJRHMgaXMgc28gd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBwcmVzZW50DQo+ PmRlcGxveW1lbnQgYW5kIG5vdCwgZm9yIGV4YW1wbGUsIHVuaXF1ZSBiZXR3ZWVuIGRvbWFpbnMu ICBUaGlzIG1heSBiZQ0KPj5jb21tb24ga25vd2xlZGdlIGluIHRoZSB3b3JsZCBvZiBPU1BGLCBi dXQgd2Fzbqn2dCB0byBtZSAoYXQgbGVhc3Qgbm90DQo+PmluaXRpYWxseSkuICBJdCBjb3VsZCBi ZSBnb29kIHRvIGFkZCBhIHNlbnRlbmNlIGFib3V0IHRoZSBjb250ZXh0IG9mDQo+PlJvdXRlciBJ RCB1bmlxdWVuZXNzIGVhcmx5IG9uIGluIHRoZSBkb2N1bWVudC4NCj4NCj5JIHdpbGwgYWRkIGEg c3RhdGVtZW50IHRvIHNlY3Rpb24gNS4NCj4NCj4+DQo+PkFsc28gcmVnYXJkaW5nIHVuaXF1ZW5l c3Mgb2YgdGhlIElELCBTZWN0aW9uIDUsIKn4T1NQRnYzIFJvdXRlciBJRA0KPj5TZWxlY3Rpb26p 9ywgaW5kaWNhdGVzIHRoYXQgYSBwc2V1ZG8tcmFuZG9tIG51bWJlciBTSE9VTEQgYmUgdXNlZCB0 bw0KPj5kZXJpdmUgdGhlIFJvdXRlciBJRC4gIExhdGVyIGluIHRoYXQgZmlyc3QgcGFyYWdyYXBo OiCp+FRoZSBnZW5lcmF0aW9uDQo+PnNob3VsZCBiZSBzZWVkZWQgd2l0aCBhIHZhcmlhYmxlIHRo YXQgaXMgbGlrZWx5IHRvIGJlIHVuaXF1ZSBpbiB0aGUNCj4+YXBwbGljYWJsZSBPU1BGdjMgcm91 dGVyIGRlcGxveW1lbnQuqfcgIFNob3VsZCB0aGF0IKn4c2hvdWxkqfcgYmUgqfhTSE9VTESp9z8N Cj4NCj5ZZXMgLSB0aGVzZSB0d28gc2VudGVuY2VzIGRlZmluaXRlbHkgU0hPVUxEIGJlIGNvbnNp c3RlbnQuDQo+DQo+Pg0KPj5UaGUgZG9jdW1lbnQgY2xlYXJseSByZWNvZ25pemVzIHRoZSBwb3Nz aWJpbGl0eSBmb3IgUm91dGVyIElEIGNvbGxpc2lvbnMsDQo+PmFuZCB0aGVyZSBkb2VzIG5vdCBh cHBlYXIgdG8gYmUgYSBuZWVkIGZvciBhIGNyeXB0b2dyYXBoaWNhbGx5IHNvdW5kDQo+PnBzZXVk by1yYW5kb20gbnVtYmVyIGdlbmVyYXRpb24gLSBqdXN0IGVub3VnaCBlbnRyb3B5IHRvIG1ha2Ug dGhlIFJvdXRlcg0KPj5JRCB1bmlxdWUgd2l0aGluIHRoZSBkZXBsb3ltZW50IGRvbWFpbiwgYW5k IHRoZQ0KPj5Sb3V0ZXItSGFyZHdhcmUtRmluZ2VycHJpbnQgVExWIChTZWN0aW9uIDcuMi4yKSBp cyBwcmVzZW50ZWQgYXMgYmVpbmcNCj4+ZW5vdWdoLg0KPg0KPkRvIHlvdSBmZWVsIHRoYXQgYSBz dGF0ZW1lbnQgd2l0aCByZXNwZWN0IHRvIHRoZSBwc2V1ZG8tcmFuZG9tIGFsZ29yaXRobQ0KPmlz IG5lY2Vzc2FyeT8gSWYgc28sIGNhbiB5b3Ugc3VnZ2VzdCBzb21lIHRleHQ/DQo+DQo+DQo+Pg0K Pj5CZWNhdXNlIHRoaXMgZG9jdW1lbnQgZXNzZW50aWFsbHkgZXhwbGFpbnMgdGhlIE9TUEZ2MyBk ZWZhdWx0cyBhIHJvdXRlcg0KPj5zaG91bGQgaGF2ZSBpbiBvcmRlciB0byBzdXBwb3J0IGF1dG8t Y29uZmlndXJhdGlvbiwgSSBwcmVzdW1lZCB0aGF0IHRoZQ0KPj5zZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBwcm92aWRlZCBpbiBwcmV2aW91cyBPU1BGdjMgZG9jdW1lbnRzIHdvdWxkDQo+PmVzc2Vu dGlhbGx5IGJlIGluIGVmZmVjdCBoZXJlLiAgVGhpcyBpc26p9nQgZXhwbGljaXRseSBzdGF0ZWQg aW4gdGhlDQo+PlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGJ1dCBjb3VsZCBiZSB3 aXRob3V0IGhhcm0sIHNob3VsZCB0aGV5DQo+PmFwcGx5IGhlcmUuICBUaGUgYm90dG9tIGxpbmUg Zm9yIG1lIGlzIHRoYXQgaXQgc2VlbXMgdGhhdCBPU1BGdjMNCj4+YXV0by1jb25maWd1cmF0aW9u IGZhdm9ycyB1c2FiaWxpdHkgb3ZlciBzZWN1cml0eSwgYnV0IHdpdGhvdXQgaWdub3JpbmcNCj4+ c2VjdXJpdHkgZW50aXJlbHkgKGUuZy4gqfhhdXRvLWNvbmZpZ3VyYXRpb24gY2FuIGFsc28gYmUg Y29tYmluZWQgd2l0aA0KPj5wYXNzd29yZCBjb25maWd1cmF0aW9uIG9yIGZ1dHVyZSBleHRlbnNp b25zIGZvciBhdXRvbWF0aWMgcGFpcmluZyBiZXR3ZWVuDQo+PmRldmljZXMuqfcpLg0KPg0KPkkg YWdyZWUgd2l0aCB0aGUgYWJvdmUgZXhjZXB0IHRoYXQgdGhlIGRvY3VtZW50IGRvZXNuJ3QgYWRk cmVzcyBhbGwgdGhlDQo+YXZhaWxhYmxlIE9TUEZ2MyBzZWN1cml0eSBvcHRpb25zLiBMZXQgbWUg YWRkIGEgcGFyYWdyYXBoLg0KPg0KPkkgd2lsbCBwcm92aWRlIHNvbWUgdXBkYXRlZCB0ZXh0IGZv ciByZXZpZXcgcHJpb3IgdG8gcmVwdWJsaXNoaW5nLg0KPg0KPlRoYW5rcywNCj5BY2VlIA0KPg0K Pg0KDQo= From nobody Wed Jan 14 00:18:04 2015 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 936D81A9107; Wed, 14 Jan 2015 00:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] 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 fUgs73EElVnd; Wed, 14 Jan 2015 00:17:55 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEC41A90F7; Wed, 14 Jan 2015 00:17:54 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud3.xs4all.net with ESMTP id fkHq1p00U4VN29601kHqfj; Wed, 14 Jan 2015 09:17:51 +0100 Received: from AMontpellier-654-1-171-51.w92-145.abo.wanadoo.fr ([92.145.38.51]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 14 Jan 2015 09:17:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Jan 2015 09:17:50 +0100 From: peter van der Stok To: robert.cragie@gridmerge.com Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <54AD33DA.5080006@gridmerge.com> References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> <54AD33DA.5080006@gridmerge.com> Message-ID: <453df83f266b93c62a0eba7a871fbec8@xs4all.nl> X-Sender: stokcons@xs4all.nl (q1rd0nXiJi9stxs0iwKHBlJF1R8+bCWL) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-roll-admin-local-policy.all@tools.ietf.org, iesg@ietf.org, consultancy@vanderstok.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 08:17:58 -0000 Hi all, I propose the following additions to the draft: - Add a section 4.3 Encryption rules With content: Incoming MPL4 messages, encrypted at layer 2, MUST be encrypted at layer 2 at all outgoing interfaces. This is done either by decrypting at the incoming interface and encrypting at the outgoing interface with the appropriate keys and encryption algorithm, or by sending the MPL4 message unmodified at the outgoing interface. Incoming MPL4 messages which are not encrypted at layer 2 MUST not be encrypted at layer 2 at the outgoing interfaces. - Add text to section 7 An attacker can send an MPL4 message with the effect that MPL4 messages are sent to the connected link or mesh. This possibly unwanted extension of the MPL4 zone is limited to the enveloping zone. Its duration is limited by MPL_CHECK_INT parameter. A manager of the MPL4 router can set MPL_enabled to FALSE on certain interfaces to restrict this misuse even more. In the worst case the attacker is located on an open wifi link where the IEEE802.11 interface is connected to a MPL4 router connected to other mesh interfaces. The rules of section 4.3 protect the integrity of the MPL4 messages, and prevent that MPL4 messages from the attacker are accepted by nodes that are part of a mesh protected at layer 2. I think this covers the cases coming forward in the discussion. Looking forward to improvements on the proposed text. Greetings, peter Robert Cragie schreef op 2015-01-07 14:25: > Steve, > > My comments inline, bracketed by . > > Robert > > On 02/01/2015 18:26, Steve.Hanna@infineon.com wrote: >> Peter, >> >> Thanks for your prompt response. I have added some more comments >> below, >> delimited with . >> >> Steve >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Friday, January 02, 2015 5:19 AM >> To: Hanna Steve (IFNA CCS SMD AMR) >> Cc: secdir@ietf.org; iesg@ietf.org; >> draft-ietf-roll-admin-local-policy.all@tools.ietf.org >> Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02 >> >> Dear Steve, >> >> thanks for the comments. I will respond below to the points you raise. >> >> Greetings, Peter >> >> Steve.Hanna@infineon.com schreef op 2014-12-30 13:55: >> >>> This document describes a technique for automatically managing the >>> boundaries of the admin-local multicast scope in a border router, >>> using MPL (Multicast Protocol for Low power and Lossy Networks). >> >> Correct >> >>> In my view, this document is Not Ready. >>> >>> The document is hard to understand. For example, the acronyms MPL and >>> MPL4 are used throughout the document but they are not defined. >> >> You are the third to remark on this point. Adrian did suggestions to >> improve the document with a definition of MPL, that we will take over. >> MPL4 concepts are defined in section 1.2. >> >> >> I'm happy to see that you'll be adding a definition of MPL. That's >> good. >> >> While it's true that section 1.2 defines several terms that include >> MPL4 >> (e.g., "MPL4 message"), the term "MPL4" is never defined anywhere. >> I found that confusing. >> >>> After reading the document several times, I have concluded that >>> section 3.2 contains the most important part of the document: an >>> algorithm for automatically defining the boundaries of the >>> admin-local >>> multicast scope using MPL. This section basically says that a border >>> router should periodically send an MPL message on all interfaces to >>> the ALL_MPL_FORWARDERS multicast address with admin-local scope. It >>> should also listen for such messages on all interfaces. If it >>> receives >>> such a message, that interface should be marked as part of the >>> admin-local scope. >>> >>> This algorithm seems problematic from a security standpoint. Because >>> any device on a network can send an MPL message to the >>> ALL_MPL_FORWARDERS multicast address with admin-local scope, the >>> boundaries of the admin-local multicast scope can be expanded by >>> attackers fairly easily. > I guess it depends what you mean by "fairly easily". An attacker > in this case would have interfaces on more than one network and would > have to be authenticated on all networks in question. The attack > scenario may be just to attach to one network and then forward into > other network(s) which would not originally be considered part of the > admin-local scope (which is I think what you are saying below) but it > still has to authenticate to the network being attacked and obtain the > relevant key before its interface on that network can validly receive > a MPL4 message. >>> Such manipulation may permit nodes that >>> should be outside a particular administrative domain to join that >>> domain and participate in receiving and sending multicast traffic >>> within that domain. The implications of such an attack are not clear >>> to me because I am not familiar with the protocols and devices that >>> use admin-local multicast scope. However, it seems likely that >>> expanding the admin-local multicast scope will permit external >>> attackers to more easily monitor multicast traffic that should be >>> private and to inject multicast messages into a relatively trusted >>> domain. > Again, it has to have been authenticated to one or more networks > and obtained the relevant key before it can do this. >> >> In the discussion with Joel, we came to the conclusion that we were >> not >> very clear with respect to the administrative zone specification. >> We suggested to limit the mpl admin-local scope within one zone. >> The text will be extended to include this extra limit on the boundary >> of >> admin-local-scope. >> The extent of the scope does not specify anything about the contents >> of >> the MPL messages. >> It is expected that MPL messages are encrypted depending on the wanted >> security level. >> Monitoring by an attacker limits itself to counting messages, which is >> already possible on wireless links any way. >> To inject messages, the attacker should know the keys necessary to >> encrypt. >> When messages are not encrypted they are already readable on the >> wireless links, and the monitoring by extending the mpl-admin-local >> scope does not increase the vulnerability to snooping the messages. >> >> >> Please send me a copy of your new text limiting the admin-local scope >> to one zone. I don't see how this will help but maybe the new text >> will >> make it clear. >> >> You just stated that "It is expected that MPL messages are encrypted". >> However, this is never stated in draft-ietf-roll-trickle-mcast-11.txt >> or in >> draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no mention >> of >> encryption in those documents at all. If the security of your design >> depends on this encryption, you'd better talk about it somewhere! >> >> Now I'd like to investigate the security provided by this encryption. >> Are you expecting that application-layer encryption will be used? >> I suppose not because that would require extensive description >> And you provided none. Probably you're thinking about link-layer >> encryption such as that provided by IEEE 802.11i. However, I don't >> think that such encryption will prevent the attacks that I described. >> >> A border router frequently spans networks that are part of multiple >> administrative domains. Your current design (even with link >> encryption) >> means that any device connected to any of these networks can dictate >> the boundaries of the admin-local scope. Is it really desirable to >> trust >> all those devices to that extent? I think not. >> > > The concept of scope, network boundary and security boundary are all > somewhat orthogonal. RFC7346 acknowledges this with additional text > and draft-ietf-roll-admin-local-policy explains how automatic > configuration for realm-local scope occurs in relation to a network > identifier, which then links network boundary and realm-local scope. > However, there isn't necessarily a one-to-one correspondence between > security boundary and network boundary even though it often happens in > practice, e.g. a WPA2 key for an 802.11 WLAN or network key for ZigBee > IP WPAN, for example. Assuming this link-layer encryption, I don't > think the attacks can take place as an attacker would have to > authenticate itself to the network being attacked first or else it > would not be able to validly received the MPL4 message. > > It is true that a border router configured with multiple MPL-enabled > interfaces does indeed by implication expand the admin-local scope, > however it is not obliged to have all its interfaces MPL-enabled; this > is part of configuration as well, potentially controllable by some > superordinate entity. > > Perhaps we need some extra text to explain this. > >> >>> In addition to this fundamental concern, I have a few minor concerns >>> about the readability of the document. However, I seem to have >>> mislaid >>> my notes during the holidays. Because this review is already late and >>> I'm on vacation, I will send the review now and follow up with the >>> minor concerns at a later date if I can find them when I return to >>> the >>> office. >> >> If you find terms which are not defined in this draft, >> ietf-rol-trickle-mcast or RFC7346, I will be happy to extend the >> definitions of section 1.2. >> >> >> OK, I'll look for my notes. However, the most important aspect of >> my review is the security issue described above. >> >> From nobody Wed Jan 14 03:09:10 2015 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 6CA0B1B2C4E; Wed, 14 Jan 2015 03:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QUu3WfaLuJJM; Wed, 14 Jan 2015 03:08:40 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A6A851B2C4B; Wed, 14 Jan 2015 03:08:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 88E2C2CC5F; Wed, 14 Jan 2015 13:08:37 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aed7SFMvQdTh; Wed, 14 Jan 2015 13:08:36 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 3C80F2CC4D; Wed, 14 Jan 2015 13:08:23 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_4523D412-E52D-4825-A1B9-BEE1DD302479"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: Date: Wed, 14 Jan 2015 13:08:20 +0200 Message-Id: References: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org" , The IESG Subject: Re: [secdir] SecDir review of draft-ietf-ospf-ospfv3-autoconfig 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, 14 Jan 2015 11:08:46 -0000 --Apple-Mail=_4523D412-E52D-4825-A1B9-BEE1DD302479 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=euc-kr Adam, Many thanks for your review. I agree with Acee=A1=AFs suggested edits. Jari On 14 Jan 2015, at 04:07, Acee Lindem (acee) wrote: > Hi Adam,=20 > Here are the updates I=A1=AFm proposing to address your comments: >=20 > *** 180,185 **** > --- 180,188 ---- > Thanks to Martin Vigoureux for Routing Area Directorate review and > comments. >=20 > + Thanks to Adam Montville for Security Area Directorate review and > + comments. > + > Special thanks go to Markus Stenberg for his implementation of = this > specification in Bird. >=20 > *************** >=20 > *** 451,464 **** >=20 > 5. OSPFv3 Router ID Selection >=20 > ! An OSPFv3 router requires a unique Router ID for correct protocol > ! operation. An OSPFv3 router implementing this specification will > ! select a router-id that has a high probability of uniqueness. A > ! pseudo-random number SHOULD be used for the OSPFv3 Router ID. = The > ! generation should be seeded with a variable that is likely to be > ! unique in the applicable OSPFv3 router deployment. A good choice = of > ! seed would be some portion or hash of the = Router-Hardware-Fingerprint > ! as described in Section 7.2.2. >=20 > Since there is a possibility of a Router ID collision, duplicate > Router ID detection and resolution are required as described in > --- 451,465 ---- >=20 > 5. OSPFv3 Router ID Selection >=20 > ! An OSPFv3 router requires a unique Router ID within the OSPFv3 > ! routing domain for correct protocol operation. An OSPFv3 router > ! implementing this specification will select a router-id that has = a > ! high probability of uniqueness. A pseudo-random number SHOULD be > ! used for the OSPFv3 Router ID. The generation SHOULD be seeded = with > ! a variable that is likely to be unique in the applicable OSPFv3 > ! router deployment. A good choice of seed would be some portion = or > ! hash of the Router-Hardware-Fingerprint as described in > ! Section 7.2.2. >=20 > Since there is a possibility of a Router ID collision, duplicate > Router ID detection and resolution are required as described in > *************** >=20 > *** 799,810 **** > automatic pairing between devices. These mechanisms can help = provide > an automatically configured, securely routed network. >=20 > ! > ! > ! > ! > ! > ! >=20 >=20 >=20 > --- 799,810 ---- > automatic pairing between devices. These mechanisms can help = provide > an automatically configured, securely routed network. >=20 > ! In deployments where stronger authentification or encryption is > ! required, OSPFv3 IPsec [OSPFV3-IPSEC] or stronger OSPFv3 > ! Authentication trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be = used > ! at the expense of additional configuration. The configuration = and > ! operational description of such deployments is beyond the scope = of > ! this document. >=20 >=20 >=20 > *************** >=20 >=20 > Thanks, > Acee=20 >=20 > On 1/13/15, 8:14 PM, "Acee Lindem (acee)" wrote: >=20 >> Hi Adam,=20 >>=20 >> On 1/13/15, 12:26 PM, "Adam W. Montville" = >> wrote: >>=20 >>> 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 draft is ready with comments/nits. >>>=20 >>> Comments >>> The document describes necessary mechanisms for OSPFv3 to be >>> self-configuring in environments requiring such (e.g. IPv6 home >>> networks). >>>=20 >>> A couple of things stood out to me. First, I inferred from the = document >>> that the uniqueness of Router IDs is so within the context of the = present >>> deployment and not, for example, unique between domains. This may = be >>> common knowledge in the world of OSPF, but wasn=A9=F6t to me (at = least not >>> initially). It could be good to add a sentence about the context of >>> Router ID uniqueness early on in the document. >>=20 >> I will add a statement to section 5. >>=20 >>>=20 >>> Also regarding uniqueness of the ID, Section 5, =A9=F8OSPFv3 Router = ID >>> Selection=A9=F7, indicates that a pseudo-random number SHOULD be = used to >>> derive the Router ID. Later in that first paragraph: =A9=F8The = generation >>> should be seeded with a variable that is likely to be unique in the >>> applicable OSPFv3 router deployment.=A9=F7 Should that =A9=F8should=A9= =F7 be =A9=F8SHOULD=A9=F7? >>=20 >> Yes - these two sentences definitely SHOULD be consistent. >>=20 >>>=20 >>> The document clearly recognizes the possibility for Router ID = collisions, >>> and there does not appear to be a need for a cryptographically sound >>> pseudo-random number generation - just enough entropy to make the = Router >>> ID unique within the deployment domain, and the >>> Router-Hardware-Fingerprint TLV (Section 7.2.2) is presented as = being >>> enough. >>=20 >> Do you feel that a statement with respect to the pseudo-random = algorithm >> is necessary? If so, can you suggest some text? >>=20 >>=20 >>>=20 >>> Because this document essentially explains the OSPFv3 defaults a = router >>> should have in order to support auto-configuration, I presumed that = the >>> security considerations provided in previous OSPFv3 documents would >>> essentially be in effect here. This isn=A9=F6t explicitly stated in = the >>> Security Considerations section, but could be without harm, should = they >>> apply here. The bottom line for me is that it seems that OSPFv3 >>> auto-configuration favors usability over security, but without = ignoring >>> security entirely (e.g. =A9=F8auto-configuration can also be = combined with >>> password configuration or future extensions for automatic pairing = between >>> devices.=A9=F7). >>=20 >> I agree with the above except that the document doesn't address all = the >> available OSPFv3 security options. Let me add a paragraph. >>=20 >> I will provide some updated text for review prior to republishing. >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >=20 --Apple-Mail=_4523D412-E52D-4825-A1B9-BEE1DD302479 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUtk4kAAoJEM80gCTQU46qVEkP/3AZGuEmg1ME0Lc6D3sFvYHy dSp/lGB7mWY6HOkMSnEZllNFrvFtV4QbNcmEH8ZQMaW+L/G9u8jbYv7Kyp7NeBY8 o+cA5zxQbszKfFjXMN5ILAew0U8ni1LXOZ0yplGw/MiapdESHyihWP/LbQSyMyk4 B54dmL8e+xpBWD+YJiQxUb2BiT/jtc0BWH3eXRXKeZ4OMze9U8JbKLkFSBHPfm+N kS+baRjvC1dfUnHe+afwb9ISATK8Z+Pcrz8RBO8sUlpPOwvQZZ86oNUF8iCZNnvr 6mslbbBfRjcqhdFlIodkxu7rfWHDRhWefoyYlo7lGAflPsQrUaNkibOnD3Q+eN/i fqXqZiY2Tg+lwkw8J3y/f5F5PckfbSlvgZ4wuVEcesTKlodjOcnKwsa2SL8ItIa7 3bVJ+1OUr587dz4kFphRRRRmvYxdMAQoEekS/pR/jQ+OjX62IrbNysRF7Ux1ZCXj aRj+VX1qf8UgziCJqs2XXfw58cMg92H4cNlb7WPngj3L1OBBlJ5mEkQts1CNDV0f NuyBnhALjsGgPoT5G8EZa4LBBOeEkb076dBL3qa4HjVMG8Ipfx65o1Ji6KVxo0hS u0wNTU2dbSs/qRxIbfJZmlaieVnhudDG0GHRQMH6Tst+XIvYjwtpevyC4pyZrB60 1Q3JaY7Y5scnMLCeObuU =+C93 -----END PGP SIGNATURE----- --Apple-Mail=_4523D412-E52D-4825-A1B9-BEE1DD302479-- From nobody Wed Jan 14 09:36:00 2015 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 1441A1A912C; Wed, 14 Jan 2015 09:35:56 -0800 (PST) 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 3gyW8sc7HsGm; Wed, 14 Jan 2015 09:35:53 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8D01A9129; Wed, 14 Jan 2015 09:35:53 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id va8so9237388obc.3; Wed, 14 Jan 2015 09:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1epEf64YfM+h3Cqhojp4g4y3PJ4D+XsMahXB6dnkCqw=; b=iiP+O+GwnmoXPoJGbvZd/Fyq+mZFINY760q66o4CuKsmfqrC3j4YheLJfUsM2JxlC+ a/dZlJjwqyOJssS8NwrpT7LgHJ6ko9RrvfwmlfDKG5gsrFaL9Zbu/YczcVNOvVSr6Cxb GL0yt2d9jep/kfULZgUXy9LCporHrpbXb0RZR5uedusls1F9HvxcF3Gpa6QOIbLcFLaj KZ1ehUU7Aj9emwgbxU4Sjf1Yzp4cLLALg34ehddbIR9k12D9BHi8Yq0LdCAff+lzc24Z 5PZf/pQsxk7HdERiaJ5BwgnknDwzQC4yr9uvB8MbGNuCcXWZLfD81By4DDFt4nWiQtol /O3g== X-Received: by 10.202.52.131 with SMTP id b125mr2973634oia.93.1421256952608; Wed, 14 Jan 2015 09:35:52 -0800 (PST) Received: from ?IPv6:2602:306:3406:4f00:e07a:916d:2608:e39b? ([2602:306:3406:4f00:e07a:916d:2608:e39b]) by mx.google.com with ESMTPSA id o5sm12333942obz.9.2015.01.14.09.35.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 09:35:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Adam W. Montville" In-Reply-To: Date: Wed, 14 Jan 2015 11:35:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <12EC5C84-0AA7-44FA-B571-5BD1A792E21D@gmail.com> References: <47E19730-5BE8-4CC1-9DB3-A341465A5BDB@gmail.com> To: Jari Arkko X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "draft-ietf-ospf-ospfv3-autoconfig.all@tools.ietf.org" , "Acee Lindem \(acee\)" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-ospf-ospfv3-autoconfig 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, 14 Jan 2015 17:35:56 -0000 Glad to be of service. It all looks good to me. > On Jan 14, 2015, at 5:08 AM, Jari Arkko wrote: >=20 > Adam, >=20 > Many thanks for your review. I agree with Acee=E2=80=99s suggested = edits. >=20 > Jari >=20 > On 14 Jan 2015, at 04:07, Acee Lindem (acee) wrote: >=20 >> Hi Adam,=20 >> Here are the updates I=E2=80=99m proposing to address your comments: >>=20 >> *** 180,185 **** >> --- 180,188 ---- >> Thanks to Martin Vigoureux for Routing Area Directorate review and >> comments. >>=20 >> + Thanks to Adam Montville for Security Area Directorate review = and >> + comments. >> + >> Special thanks go to Markus Stenberg for his implementation of = this >> specification in Bird. >>=20 >> *************** >>=20 >> *** 451,464 **** >>=20 >> 5. OSPFv3 Router ID Selection >>=20 >> ! An OSPFv3 router requires a unique Router ID for correct = protocol >> ! operation. An OSPFv3 router implementing this specification = will >> ! select a router-id that has a high probability of uniqueness. A >> ! pseudo-random number SHOULD be used for the OSPFv3 Router ID. = The >> ! generation should be seeded with a variable that is likely to be >> ! unique in the applicable OSPFv3 router deployment. A good = choice of >> ! seed would be some portion or hash of the = Router-Hardware-Fingerprint >> ! as described in Section 7.2.2. >>=20 >> Since there is a possibility of a Router ID collision, duplicate >> Router ID detection and resolution are required as described in >> --- 451,465 ---- >>=20 >> 5. OSPFv3 Router ID Selection >>=20 >> ! An OSPFv3 router requires a unique Router ID within the OSPFv3 >> ! routing domain for correct protocol operation. An OSPFv3 router >> ! implementing this specification will select a router-id that has = a >> ! high probability of uniqueness. A pseudo-random number SHOULD = be >> ! used for the OSPFv3 Router ID. The generation SHOULD be seeded = with >> ! a variable that is likely to be unique in the applicable OSPFv3 >> ! router deployment. A good choice of seed would be some portion = or >> ! hash of the Router-Hardware-Fingerprint as described in >> ! Section 7.2.2. >>=20 >> Since there is a possibility of a Router ID collision, duplicate >> Router ID detection and resolution are required as described in >> *************** >>=20 >> *** 799,810 **** >> automatic pairing between devices. These mechanisms can help = provide >> an automatically configured, securely routed network. >>=20 >> ! >> ! >> ! >> ! >> ! >> ! >>=20 >>=20 >>=20 >> --- 799,810 ---- >> automatic pairing between devices. These mechanisms can help = provide >> an automatically configured, securely routed network. >>=20 >> ! In deployments where stronger authentification or encryption is >> ! required, OSPFv3 IPsec [OSPFV3-IPSEC] or stronger OSPFv3 >> ! Authentication trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be = used >> ! at the expense of additional configuration. The configuration = and >> ! operational description of such deployments is beyond the scope = of >> ! this document. >>=20 >>=20 >>=20 >> *************** >>=20 >>=20 >> Thanks, >> Acee=20 >>=20 >> On 1/13/15, 8:14 PM, "Acee Lindem (acee)" wrote: >>=20 >>> Hi Adam,=20 >>>=20 >>> On 1/13/15, 12:26 PM, "Adam W. Montville" = >>> wrote: >>>=20 >>>> 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 draft is ready with comments/nits. >>>>=20 >>>> Comments >>>> The document describes necessary mechanisms for OSPFv3 to be >>>> self-configuring in environments requiring such (e.g. IPv6 home >>>> networks). >>>>=20 >>>> A couple of things stood out to me. First, I inferred from the = document >>>> that the uniqueness of Router IDs is so within the context of the = present >>>> deployment and not, for example, unique between domains. This may = be >>>> common knowledge in the world of OSPF, but wasn=C2=B9t to me (at = least not >>>> initially). It could be good to add a sentence about the context = of >>>> Router ID uniqueness early on in the document. >>>=20 >>> I will add a statement to section 5. >>>=20 >>>>=20 >>>> Also regarding uniqueness of the ID, Section 5, =C2=B3OSPFv3 Router = ID >>>> Selection=C2=B2, indicates that a pseudo-random number SHOULD be = used to >>>> derive the Router ID. Later in that first paragraph: =C2=B3The = generation >>>> should be seeded with a variable that is likely to be unique in the >>>> applicable OSPFv3 router deployment.=C2=B2 Should that =C2=B3should=C2= =B2 be =C2=B3SHOULD=C2=B2? >>>=20 >>> Yes - these two sentences definitely SHOULD be consistent. >>>=20 >>>>=20 >>>> The document clearly recognizes the possibility for Router ID = collisions, >>>> and there does not appear to be a need for a cryptographically = sound >>>> pseudo-random number generation - just enough entropy to make the = Router >>>> ID unique within the deployment domain, and the >>>> Router-Hardware-Fingerprint TLV (Section 7.2.2) is presented as = being >>>> enough. >>>=20 >>> Do you feel that a statement with respect to the pseudo-random = algorithm >>> is necessary? If so, can you suggest some text? >>>=20 >>>=20 >>>>=20 >>>> Because this document essentially explains the OSPFv3 defaults a = router >>>> should have in order to support auto-configuration, I presumed that = the >>>> security considerations provided in previous OSPFv3 documents would >>>> essentially be in effect here. This isn=C2=B9t explicitly stated = in the >>>> Security Considerations section, but could be without harm, should = they >>>> apply here. The bottom line for me is that it seems that OSPFv3 >>>> auto-configuration favors usability over security, but without = ignoring >>>> security entirely (e.g. =C2=B3auto-configuration can also be = combined with >>>> password configuration or future extensions for automatic pairing = between >>>> devices.=C2=B2). >>>=20 >>> I agree with the above except that the document doesn't address all = the >>> available OSPFv3 security options. Let me add a paragraph. >>>=20 >>> I will provide some updated text for review prior to republishing. >>>=20 >>> Thanks, >>> Acee=20 >>>=20 >>>=20 >>=20 >=20 From nobody Wed Jan 14 13:50:21 2015 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 4C2901ACD59 for ; Wed, 14 Jan 2015 13:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 e5SX5miBHkQI for ; Wed, 14 Jan 2015 13:50:18 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA0F1ACCEB for ; Wed, 14 Jan 2015 13:50:18 -0800 (PST) Received: from [10.20.30.90] (50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91]) (authenticated bits=0) by proper.com (8.15.1/8.14.7) with ESMTPSA id t0ELoGYd021343 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2015 14:50:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-91.dsl.dynamic.fusionbroadband.com [50.1.98.91] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <34534088-F80A-4FF1-A859-5CFA456A737A@vpnc.org> Date: Wed, 14 Jan 2015 13:50:16 -0800 To: secdir Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [secdir] Secdir review of draft-holmberg-dispatch-iotl 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, 14 Jan 2015 21:50:19 -0000 Greetings again. draft-holmberg-dispatch-iotl describes a new SIP URI = parameter that indicates "indicate that the entity associated with the = address, or an entity responsible for the host part of the address, = represents the end of a specific traffic leg (or multiple traffic = legs)". The security considerations are short: The information SHOULD only be used for making policy decisions based on the role by nodes within the same trust domain [RFC3325]. In addition, there MUST exist an agreement between the operators for usage of the roaming role information. URIs passed are protected as well as anything in SIP: completely if = you're actually using TLS, not at all if you're not. A MITM fiddling = with this parameter on SIP-without-TLS can cause problems, but those = problems are approximately the same as for all other parts of the = unprotected URI. I'm not a fan of having every SIP document say "if you aren't using TLS = like we said you should, you're in danger", so I think it is fine that = this one doesn't say that. There are no other significant security = considerations beyond the one above. --Paul Hoffman= From nobody Wed Jan 14 14:08:59 2015 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 8D3D91ACE01; Wed, 14 Jan 2015 14:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 uJQbq9v9D0Er; Wed, 14 Jan 2015 14:08:47 -0800 (PST) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD391ACE00; Wed, 14 Jan 2015 14:08:45 -0800 (PST) X-SBRS: None Received: from unknown (HELO mucxv002.muc.infineon.com) ([172.23.11.17]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jan 2015 23:08:44 +0100 Received: from MUCSE607.infineon.com (mucltm.muc.infineon.com [172.23.8.247]) by mucxv002.muc.infineon.com (Postfix) with ESMTPS; Wed, 14 Jan 2015 23:08:43 +0100 (CET) Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 14 Jan 2015 23:08:42 +0100 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.0995.032; Wed, 14 Jan 2015 23:08:42 +0100 From: To: , Thread-Topic: secdir review of draft-ietf-roll-admin-local-policy-02 Thread-Index: AdAff2eol7wcDrkvTNS1G9OE6YCkGQG7cxgAAA8u32AA8sgYAAF0A7KA Date: Wed, 14 Jan 2015 22:08:42 +0000 Message-ID: References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> <54AD33DA.5080006@gridmerge.com> In-Reply-To: <54AD33DA.5080006@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01D0301C.BDE28160" MIME-Version: 1.0 Archived-At: Cc: iesg@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-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: Wed, 14 Jan 2015 22:08:52 -0000 ------=_NextPart_000_005F_01D0301C.BDE28160 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0060_01D0301C.BDE28160" ------=_NextPart_001_0060_01D0301C.BDE28160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Rob, I have removed areas where we agree below and added new comments marked with . Thanks, Steve >> After reading the document several times, I have concluded that >> section 3.2 contains the most important part of the document: an >> algorithm for automatically defining the boundaries of the admin-local >> multicast scope using MPL. This section basically says that a border >> router should periodically send an MPL message on all interfaces to >> the ALL_MPL_FORWARDERS multicast address with admin-local scope. It >> should also listen for such messages on all interfaces. If it receives >> such a message, that interface should be marked as part of the >> admin-local scope. >> >> This algorithm seems problematic from a security standpoint. Because >> any device on a network can send an MPL message to the >> ALL_MPL_FORWARDERS multicast address with admin-local scope, the >> boundaries of the admin-local multicast scope can be expanded by >> attackers fairly easily. I guess it depends what you mean by "fairly easily". An attacker in this case would have interfaces on more than one network and would have to be authenticated on all networks in question. The attack scenario may be just to attach to one network and then forward into other network(s) which would not originally be considered part of the admin-local scope (which is I think what you are saying below) but it still has to authenticate to the network being attacked and obtain the relevant key before its interface on that network can validly receive a MPL4 message. I don't see why the attacker would need to have interfaces on more than one network. See the ASCII art diagram below: H1 - R - H2 Border router R has two network interfaces. H1 and H2 are hosts connected to these interfaces. If both H1 and H2 send MPL4 messages and R has MPL4 enabled on those interfaces, R will put both networks into the same admin-local multicast scope. Am I wrong? >> Such manipulation may permit nodes that >> should be outside a particular administrative domain to join that >> domain and participate in receiving and sending multicast traffic >> within that domain. The implications of such an attack are not clear >> to me because I am not familiar with the protocols and devices that >> use admin-local multicast scope. However, it seems likely that >> expanding the admin-local multicast scope will permit external >> attackers to more easily monitor multicast traffic that should be >> private and to inject multicast messages into a relatively trusted >> domain. Again, it has to have been authenticated to one or more networks and obtained the relevant key before it can do this. > > In the discussion with Joel, we came to the conclusion that we were not > very clear with respect to the administrative zone specification. > We suggested to limit the mpl admin-local scope within one zone. > The text will be extended to include this extra limit on the boundary of > admin-local-scope. > The extent of the scope does not specify anything about the contents of > the MPL messages. > It is expected that MPL messages are encrypted depending on the wanted > security level. > Monitoring by an attacker limits itself to counting messages, which is > already possible on wireless links any way. > To inject messages, the attacker should know the keys necessary to > encrypt. > When messages are not encrypted they are already readable on the > wireless links, and the monitoring by extending the mpl-admin-local > scope does not increase the vulnerability to snooping the messages. > > > Please send me a copy of your new text limiting the admin-local scope > to one zone. I don't see how this will help but maybe the new text will > make it clear. > > You just stated that "It is expected that MPL messages are encrypted". > However, this is never stated in draft-ietf-roll-trickle-mcast-11.txt or in > draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no mention of > encryption in those documents at all. If the security of your design > depends on this encryption, you'd better talk about it somewhere! > > Now I'd like to investigate the security provided by this encryption. > Are you expecting that application-layer encryption will be used? > I suppose not because that would require extensive description > And you provided none. Probably you're thinking about link-layer > encryption such as that provided by IEEE 802.11i. However, I don't > think that such encryption will prevent the attacks that I described. > > A border router frequently spans networks that are part of multiple > administrative domains. Your current design (even with link encryption) > means that any device connected to any of these networks can dictate > the boundaries of the admin-local scope. Is it really desirable to trust > all those devices to that extent? I think not. > The concept of scope, network boundary and security boundary are all somewhat orthogonal. RFC7346 acknowledges this with additional text and draft-ietf-roll-admin-local-policy explains how automatic configuration for realm-local scope occurs in relation to a network identifier, which then links network boundary and realm-local scope. However, there isn't necessarily a one-to-one correspondence between security boundary and network boundary even though it often happens in practice, e.g. a WPA2 key for an 802.11 WLAN or network key for ZigBee IP WPAN, for example. Assuming this link-layer encryption, I don't think the attacks can take place as an attacker would have to authenticate itself to the network being attacked first or else it would not be able to validly received the MPL4 message. It is true that a border router configured with multiple MPL-enabled interfaces does indeed by implication expand the admin-local scope, however it is not obliged to have all its interfaces MPL-enabled; this is part of configuration as well, potentially controllable by some superordinate entity. Perhaps we need some extra text to explain this. Certainly, if extending the admin-local scope has no security implications, there's no security problem here. However, that is probably not a universal understanding. You should explain this issue in the Security Considerations section and describe the circumstances when it is a problem and when it is not. This will equip the reader to decide what to do. Just because a host has the keys needed to join one network does not mean that they should be permitted to change the admin-local scope boundaries between that network and all other networks joined via border routers. ------=_NextPart_001_0060_01D0301C.BDE28160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rob,

 

I have = removed areas where we agree below and added new comments marked with = <steve2>.

 

Thanks,

 

Steve

 

>> After reading the document several times, = I have concluded that

>> = section 3.2 contains the most important part of the document: = an

>> algorithm for = automatically defining the boundaries of the = admin-local

>> multicast = scope using MPL. This section basically says that a = border

>> router should = periodically send an MPL message on all interfaces to

>> the ALL_MPL_FORWARDERS multicast address = with admin-local scope. It

>> should also listen for such messages on = all interfaces. If it receives

>> such a message, that interface should be = marked as part of the

>> = admin-local scope.

>> 

>> This algorithm seems problematic from a = security standpoint. Because

>> any device on a network can send an MPL = message to the

>> = ALL_MPL_FORWARDERS multicast address with admin-local scope, = the

>> boundaries of the = admin-local multicast scope can be expanded by

>> attackers fairly easily.

<rcc>I guess it depends what you mean by = "fairly easily". An attacker in

this case would have interfaces on more than one = network and would have

to be = authenticated on all networks in question. The attack scenario may =

be just to attach to one network = and then forward into other network(s)

which would not originally be considered part of = the admin-local scope

(which is I = think what you are saying below) but it still has to

authenticate to the network being attacked and = obtain the relevant key

before = its interface on that network can validly receive a MPL4 =

message.</rcc>

 

<steve2>I don't = see why the attacker would need to have interfaces = on

more than one network. See the ASCII art diagram = below:

 

H1 – R – H2

 

Border router R has two = network interfaces. H1 and H2 are hosts

connected to these = interfaces. If both H1 and H2 send MPL4 messages

and R has MPL4 enabled = on those interfaces, R will put both networks

into the same = admin-local multicast scope. Am I wrong?

</steve2>

 

>> Such manipulation may permit nodes = that

>> should be outside a = particular administrative domain to join that

>> domain and participate in receiving and = sending multicast traffic

>> = within that domain. The implications of such an attack are not = clear

>> to me because I am = not familiar with the protocols and devices that

>> use admin-local multicast scope. However, = it seems likely that

>> = expanding the admin-local multicast scope will permit = external

>> attackers to = more easily monitor multicast traffic that should be

>> private and to inject multicast messages = into a relatively trusted

>> = domain.

<rcc>Again, it has = to have been authenticated to one or more networks

and obtained the relevant key before it can do = this.</rcc>

> = <peter>

> In the = discussion with Joel, we came to the conclusion that we were = not

> very clear with respect = to the administrative zone specification.

> We suggested to limit the mpl admin-local = scope within one zone.

> The = text will be extended to include this extra limit on the boundary = of

> = admin-local-scope.

> The extent = of the scope does not specify anything about the contents = of

> the MPL = messages.

> It is expected that = MPL messages are encrypted depending on the wanted

> security level.

> Monitoring by an attacker limits itself to = counting messages, which is

> = already possible on wireless links any way.

> To inject messages, the attacker should know = the keys necessary to

> = encrypt.

> When messages are = not encrypted they are already readable on the

> wireless links, and the monitoring by = extending the mpl-admin-local

> = scope does not increase the vulnerability to snooping the = messages.

> = </peter>

> = <steve>

> Please send me = a copy of your new text limiting the admin-local scope

> to one zone. I don't see how this will help = but maybe the new text will

> = make it clear.

> 

> You just stated that "It is expected that = MPL messages are encrypted".

> However, this is never stated in = draft-ietf-roll-trickle-mcast-11.txt or in

> draft-ietf-roll-admin-local-policy-02.txt. In = fact, there's no mention of

> = encryption in those documents at all. If the security of your = design

> depends on this = encryption, you'd better talk about it somewhere!

> 

> Now I'd like to investigate the security = provided by this encryption.

> = Are you expecting that application-layer encryption will be = used?

> I suppose not because = that would require extensive description

> And you provided none. Probably you're = thinking about link-layer

> = encryption such as that provided by IEEE 802.11i. However, I = don't

> think that such = encryption will prevent the attacks that I described.

> 

> A border router frequently spans networks that = are part of multiple

> = administrative domains. Your current design (even with link = encryption)

> means that any = device connected to any of these networks can dictate

> the boundaries of the admin-local scope. Is it = really desirable to trust

> all = those devices to that extent? I think not.

> </steve>

<rcc>

The concept of scope, network boundary and security = boundary are all

somewhat = orthogonal. RFC7346 acknowledges this with additional text and =

draft-ietf-roll-admin-local-policy explains how = automatic configuration

for = realm-local scope occurs in relation to a network identifier, which =

then links network boundary and = realm-local scope. However, there isn't

necessarily a one-to-one correspondence between = security boundary and

network = boundary even though it often happens in practice, e.g. a WPA2 =

key for an 802.11 WLAN or network = key for ZigBee IP WPAN, for example.

Assuming this link-layer encryption, I don't think = the attacks can take

place as an = attacker would have to authenticate itself to the network =

being attacked first or else it = would not be able to validly received

the MPL4 message.

 

It is = true that a border router configured with multiple MPL-enabled =

interfaces does indeed by = implication expand the admin-local scope,

however it is not obliged to have all its = interfaces MPL-enabled; this

is = part of configuration as well, potentially controllable by some =

superordinate = entity.

 

Perhaps we need some extra text to explain = this.

</rcc>

 

<steve2>

Certainly, if extending = the admin-local scope has no security

implications, = there’s no security problem here. However, = that

is probably not a universal understanding. You = should explain

this issue in the Security Considerations section = and describe

the circumstances when it is a problem and when it = is not.

This will equip the reader to decide what to do. = Just because

a host has the keys needed to join one network = does not

mean that they should be permitted to change the = admin-local

scope boundaries between that network and all = other networks

joined via border routers.

</steve2>

 

------=_NextPart_001_0060_01D0301C.BDE28160-- ------=_NextPart_000_005F_01D0301C.BDE28160 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDExNDIyMDgzOVowIwYJKoZIhvcNAQkEMRYEFI+iz4V01/eg1wgsSKeBWNvZcj6TMHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAEQ5YkRiE8DkzI1NXl1I9XVz+H3OAOp4JmPO1uL5JCi0L+WswCIu k4rfEiBszumwHQp6ZRXLtSuYl2GzToc9nDs3VyaUXcqkmd0JifioxtZG/LjKRJMllLZveyvHFQ6c Mn/kZdY+qk6VIvdutRUYXAvmdIkg4RadkqZVbQtynTme9ZodgpcMhAsNaFwucS2eaxPnYrvWki9a NvXK5LdoZns3pp0hnJdaMB8eq40X2qMI0v4SgR2hsiiqz2mLgcUvcGA965EfCDAvWDGB7PFTa6wR rzkXjzs0ov3BTwrOLA1qffecNvQxEXmr40bBlR02EkLzFqAgSdVr3IAC7AOo1O0AAAAAAAA= ------=_NextPart_000_005F_01D0301C.BDE28160-- From nobody Wed Jan 14 14:09:05 2015 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 D394D1ACE06; Wed, 14 Jan 2015 14:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 o4ZEqfUDJ5_c; Wed, 14 Jan 2015 14:08:51 -0800 (PST) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C531ACDBA; Wed, 14 Jan 2015 14:08:48 -0800 (PST) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jan 2015 23:08:48 +0100 Received: from MUCSE604.infineon.com (mucltm.muc.infineon.com [172.23.8.247]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Wed, 14 Jan 2015 23:08:47 +0100 (CET) Received: from MUCSE612.infineon.com (172.23.7.113) by MUCSE604.infineon.com (172.23.7.105) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 14 Jan 2015 23:08:46 +0100 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE612.infineon.com (172.23.7.113) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 14 Jan 2015 23:08:45 +0100 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.0995.032; Wed, 14 Jan 2015 23:08:45 +0100 From: To: , Thread-Topic: secdir review of draft-ietf-roll-admin-local-policy-02 Thread-Index: AdAff2eol7wcDrkvTNS1G9OE6YCkGQG7cxgAAA8u32AA8sgYAAFVSRYAAB6rcIA= Date: Wed, 14 Jan 2015 22:08:45 +0000 Message-ID: <297bed7738f14d039fc9caf126ad4731@MUCSE609.infineon.com> References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> <54AD33DA.5080006@gridmerge.com> <453df83f266b93c62a0eba7a871fbec8@xs4all.nl> In-Reply-To: <453df83f266b93c62a0eba7a871fbec8@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0067_01D0301C.BE918610" MIME-Version: 1.0 Archived-At: Cc: iesg@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-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: Wed, 14 Jan 2015 22:08:55 -0000 ------=_NextPart_000_0067_01D0301C.BE918610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Peter, Thanks for addressing the issue that I raised. Your proposal is not very strong. If the border router has interfaces on two networks that both have layer 2 encryption, any device on either of those networks can cause the boundaries of the admin-local scope to be changed. Am I wrong? Thanks, Steve -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: Wednesday, January 14, 2015 3:18 AM To: robert.cragie@gridmerge.com Cc: Hanna Steve (IFNA CCS SMD AMR); consultancy@vanderstok.org; secdir@ietf.org; iesg@ietf.org; draft-ietf-roll-admin-local-policy.all@tools.ietf.org Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02 Hi all, I propose the following additions to the draft: - Add a section 4.3 Encryption rules With content: Incoming MPL4 messages, encrypted at layer 2, MUST be encrypted at layer 2 at all outgoing interfaces. This is done either by decrypting at the incoming interface and encrypting at the outgoing interface with the appropriate keys and encryption algorithm, or by sending the MPL4 message unmodified at the outgoing interface. Incoming MPL4 messages which are not encrypted at layer 2 MUST not be encrypted at layer 2 at the outgoing interfaces. - Add text to section 7 An attacker can send an MPL4 message with the effect that MPL4 messages are sent to the connected link or mesh. This possibly unwanted extension of the MPL4 zone is limited to the enveloping zone. Its duration is limited by MPL_CHECK_INT parameter. A manager of the MPL4 router can set MPL_enabled to FALSE on certain interfaces to restrict this misuse even more. In the worst case the attacker is located on an open wifi link where the IEEE802.11 interface is connected to a MPL4 router connected to other mesh interfaces. The rules of section 4.3 protect the integrity of the MPL4 messages, and prevent that MPL4 messages from the attacker are accepted by nodes that are part of a mesh protected at layer 2. I think this covers the cases coming forward in the discussion. Looking forward to improvements on the proposed text. Greetings, peter Robert Cragie schreef op 2015-01-07 14:25: > Steve, > > My comments inline, bracketed by . > > Robert > > On 02/01/2015 18:26, Steve.Hanna@infineon.com wrote: >> Peter, >> >> Thanks for your prompt response. I have added some more comments >> below, >> delimited with . >> >> Steve >> >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: Friday, January 02, 2015 5:19 AM >> To: Hanna Steve (IFNA CCS SMD AMR) >> Cc: secdir@ietf.org; iesg@ietf.org; >> draft-ietf-roll-admin-local-policy.all@tools.ietf.org >> Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02 >> >> Dear Steve, >> >> thanks for the comments. I will respond below to the points you raise. >> >> Greetings, Peter >> >> Steve.Hanna@infineon.com schreef op 2014-12-30 13:55: >> >>> This document describes a technique for automatically managing the >>> boundaries of the admin-local multicast scope in a border router, >>> using MPL (Multicast Protocol for Low power and Lossy Networks). >> >> Correct >> >>> In my view, this document is Not Ready. >>> >>> The document is hard to understand. For example, the acronyms MPL and >>> MPL4 are used throughout the document but they are not defined. >> >> You are the third to remark on this point. Adrian did suggestions to >> improve the document with a definition of MPL, that we will take over. >> MPL4 concepts are defined in section 1.2. >> >> >> I'm happy to see that you'll be adding a definition of MPL. That's >> good. >> >> While it's true that section 1.2 defines several terms that include >> MPL4 >> (e.g., "MPL4 message"), the term "MPL4" is never defined anywhere. >> I found that confusing. >> >>> After reading the document several times, I have concluded that >>> section 3.2 contains the most important part of the document: an >>> algorithm for automatically defining the boundaries of the >>> admin-local >>> multicast scope using MPL. This section basically says that a border >>> router should periodically send an MPL message on all interfaces to >>> the ALL_MPL_FORWARDERS multicast address with admin-local scope. It >>> should also listen for such messages on all interfaces. If it >>> receives >>> such a message, that interface should be marked as part of the >>> admin-local scope. >>> >>> This algorithm seems problematic from a security standpoint. Because >>> any device on a network can send an MPL message to the >>> ALL_MPL_FORWARDERS multicast address with admin-local scope, the >>> boundaries of the admin-local multicast scope can be expanded by >>> attackers fairly easily. > I guess it depends what you mean by "fairly easily". An attacker > in this case would have interfaces on more than one network and would > have to be authenticated on all networks in question. The attack > scenario may be just to attach to one network and then forward into > other network(s) which would not originally be considered part of the > admin-local scope (which is I think what you are saying below) but it > still has to authenticate to the network being attacked and obtain the > relevant key before its interface on that network can validly receive > a MPL4 message. >>> Such manipulation may permit nodes that >>> should be outside a particular administrative domain to join that >>> domain and participate in receiving and sending multicast traffic >>> within that domain. The implications of such an attack are not clear >>> to me because I am not familiar with the protocols and devices that >>> use admin-local multicast scope. However, it seems likely that >>> expanding the admin-local multicast scope will permit external >>> attackers to more easily monitor multicast traffic that should be >>> private and to inject multicast messages into a relatively trusted >>> domain. > Again, it has to have been authenticated to one or more networks > and obtained the relevant key before it can do this. >> >> In the discussion with Joel, we came to the conclusion that we were >> not >> very clear with respect to the administrative zone specification. >> We suggested to limit the mpl admin-local scope within one zone. >> The text will be extended to include this extra limit on the boundary >> of >> admin-local-scope. >> The extent of the scope does not specify anything about the contents >> of >> the MPL messages. >> It is expected that MPL messages are encrypted depending on the wanted >> security level. >> Monitoring by an attacker limits itself to counting messages, which is >> already possible on wireless links any way. >> To inject messages, the attacker should know the keys necessary to >> encrypt. >> When messages are not encrypted they are already readable on the >> wireless links, and the monitoring by extending the mpl-admin-local >> scope does not increase the vulnerability to snooping the messages. >> >> >> Please send me a copy of your new text limiting the admin-local scope >> to one zone. I don't see how this will help but maybe the new text >> will >> make it clear. >> >> You just stated that "It is expected that MPL messages are encrypted". >> However, this is never stated in draft-ietf-roll-trickle-mcast-11.txt >> or in >> draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no mention >> of >> encryption in those documents at all. If the security of your design >> depends on this encryption, you'd better talk about it somewhere! >> >> Now I'd like to investigate the security provided by this encryption. >> Are you expecting that application-layer encryption will be used? >> I suppose not because that would require extensive description >> And you provided none. Probably you're thinking about link-layer >> encryption such as that provided by IEEE 802.11i. However, I don't >> think that such encryption will prevent the attacks that I described. >> >> A border router frequently spans networks that are part of multiple >> administrative domains. Your current design (even with link >> encryption) >> means that any device connected to any of these networks can dictate >> the boundaries of the admin-local scope. Is it really desirable to >> trust >> all those devices to that extent? I think not. >> > > The concept of scope, network boundary and security boundary are all > somewhat orthogonal. RFC7346 acknowledges this with additional text > and draft-ietf-roll-admin-local-policy explains how automatic > configuration for realm-local scope occurs in relation to a network > identifier, which then links network boundary and realm-local scope. > However, there isn't necessarily a one-to-one correspondence between > security boundary and network boundary even though it often happens in > practice, e.g. a WPA2 key for an 802.11 WLAN or network key for ZigBee > IP WPAN, for example. Assuming this link-layer encryption, I don't > think the attacks can take place as an attacker would have to > authenticate itself to the network being attacked first or else it > would not be able to validly received the MPL4 message. > > It is true that a border router configured with multiple MPL-enabled > interfaces does indeed by implication expand the admin-local scope, > however it is not obliged to have all its interfaces MPL-enabled; this > is part of configuration as well, potentially controllable by some > superordinate entity. > > Perhaps we need some extra text to explain this. > >> >>> In addition to this fundamental concern, I have a few minor concerns >>> about the readability of the document. However, I seem to have >>> mislaid >>> my notes during the holidays. Because this review is already late and >>> I'm on vacation, I will send the review now and follow up with the >>> minor concerns at a later date if I can find them when I return to >>> the >>> office. >> >> If you find terms which are not defined in this draft, >> ietf-rol-trickle-mcast or RFC7346, I will be happy to extend the >> definitions of section 1.2. >> >> >> OK, I'll look for my notes. However, the most important aspect of >> my review is the security issue described above. >> >> ------=_NextPart_000_0067_01D0301C.BE918610 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDExNDIyMDg0MFowIwYJKoZIhvcNAQkEMRYEFEjh6J65nCSietiU2wViPMwWGDNzMHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAG7w9MN3ruAqEznupaRQ15kaEh7jM8My5Za9NOOU+I3U2kwoSqct V+dsASsNOLC0tba9+LUrVfaxsc/XKCfyPWdA38mfq0NvjQw6ntiyVKyrQRuyl2M1JmF7K8o2u+k9 MbfMU3ElzTLAfZ1z8E9Bn8OVoI3TdCs68SSlJNmtXQbjikkGrFq3oaBtYAfTplxlYoJ1jzXGkJqv XF2Vj5yFlRMafVPHjh5O+HpBukDdqGjHgJZODaNwh/TcFJshgRB5Do4aiPsZ1flhvYV5xojX9zkY NEQDwVjTH/Ow0Mrl0IEvt4eaIFyBVqfa/uKsWab3PtZo6bBCKXzAVZjtvb1QvKkAAAAAAAA= ------=_NextPart_000_0067_01D0301C.BE918610-- From nobody Wed Jan 14 14:56:20 2015 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 4B5D81ACF58; Wed, 14 Jan 2015 14:56:19 -0800 (PST) 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 TOyyG14Lntho; Wed, 14 Jan 2015 14:56:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40CA1ACF54; Wed, 14 Jan 2015 14:56:16 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1E9AF20098; Wed, 14 Jan 2015 18:02:04 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 71EE5637FE; Wed, 14 Jan 2015 17:56:15 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5B362637F2; Wed, 14 Jan 2015 17:56:15 -0500 (EST) From: Michael Richardson To: secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org In-Reply-To: <453df83f266b93c62a0eba7a871fbec8@xs4all.nl> References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> <54AD33DA.5080006@gridmerge.com> <453df83f266b93c62a0eba7a871fbec8@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: robert.cragie@gridmerge.com, consultancy@vanderstok.org Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-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: Wed, 14 Jan 2015 22:56:19 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable peter van der Stok wrote: > Incoming MPL4 messages, encrypted at layer 2, MUST be encrypted at > layer 2 at=20 > all outgoing interfaces. This is done either by decrypting at the > incoming=20 > interface and encrypting at the outgoing interface with the appropria= te > keys this works. > by sending the MPL4 message unmodified at the > outgoing interface. This does not work in 15.4, it's just not how things work, because parts of the packet changes, so the nonces change, etc. wrote: Steve> Thanks for addressing the issue that I raised. Steve> Your proposal is not very strong. If the border router has Steve> interfaces on two networks that both have layer 2 encryption, any Steve> device on either of those networks can cause the boundaries of t= he Steve> admin-local scope to be changed. Am I wrong? I don't understand the attack. Can you explain ? All nodes with access to the raw data can replicate it elsewhere. I think that you are suggesting that some node can cause the border router = to change it's admin-local scope. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVLb0D4CLcPvd0N1lAQKEdQgAsnISIRMwpMEuaJ2y53C32IjSOXJQuZ1D zRwjLUj2nfeG0DjurcwUm6n6El6xg0HZdzpLOPGb0C/ICw2a3XlOQ8NwckMOsB0z yxyxFVgK7KiO0WUMHVZYRO5SsRsfrTLY65HKEFSh4iahvoumfYTEx9m6zgMuTEA6 mIBf9s+bQosF9DN5V8jYKvDMuV9QjSTLy+a7c9zX2apPJBsOFcgenH0rDePDedO9 28qkGrNCAKS91qmM815f6a7BNuEBUqBTMlbrsgx/exqPdMb8bzbafu8JcFxoDyWh IPsQeol6sj//YKUTfF3+UE0zSVsR5+wuBTbzQqaM3nQOOLNq69AzAQ== =r/63 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 15 10:41:16 2015 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 DC1CE1B306D for ; Thu, 15 Jan 2015 10:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 mJyx4rLswmQ8 for ; Thu, 15 Jan 2015 10:41:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28341B3073 for ; Thu, 15 Jan 2015 10:41:11 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t0FIf5Lm004277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 15 Jan 2015 20:41:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0FIf4Zt011611; Thu, 15 Jan 2015 20:41:04 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21688.2496.288355.280911@fireball.kivinen.iki.fi> Date: Thu, 15 Jan 2015 20:41:04 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: 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, 15 Jan 2015 18:41:14 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Magnus Nystrom is next in the rotation. For telechat 2015-01-22 Reviewer LC end Draft Sam Hartman T 2015-01-09 draft-farrkingel-pce-abno-architecture-14 Leif Johansson T 2014-12-25 draft-ietf-radext-radius-fragmentation-10 Ben Laurie T 2015-01-08 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 Matt Lepinski T 2015-01-14 draft-ietf-httpbis-header-compression-10 Chris Lonvick T 2015-01-14 draft-ietf-httpbis-http2-16 For telechat 2015-02-05 Sandy Murphy T 2015-01-28 draft-ietf-httpbis-rfc7238bis-02 Last calls and special requests: Dorothy Gellert 2014-12-22 draft-ietf-ippm-rate-problem-09 Tobias Gondrom 2014-12-18 draft-ietf-mpls-ldp-ipv6-15 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-12-22 draft-ietf-tsvwg-port-use-06 David Harrington 2014-12-24 draft-ietf-tsvwg-sctp-dtls-encaps-08 Jeffrey Hutzelman 2015-01-22 draft-ietf-drinks-spp-protocol-over-soap-07 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Catherine Meadows 2015-01-26 draft-ietf-l2vpn-pbb-evpn-09 Alexey Melnikov 2015-01-14 draft-ietf-opsawg-coman-probstate-reqs-03 Yoav Nir 2015-01-23 draft-ietf-tls-downgrade-scsv-03 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-08 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 -- kivinen@iki.fi From nobody Thu Jan 15 12:23:06 2015 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 B086A1B32E1; Thu, 15 Jan 2015 12:22:53 -0800 (PST) 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 tMjjY8hwsMwl; Thu, 15 Jan 2015 12:22:52 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF441B32E0; Thu, 15 Jan 2015 12:22:51 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id rd3so19573548pab.7; Thu, 15 Jan 2015 12:22:51 -0800 (PST) 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=yYui7eh0Ze+ZLB+KRnfG3nCVKuYptoGz783eRl0vU1I=; b=V91cgbcYfpyOqkXue8oNq416VYroQ1QyEo+NBd6/6edjZgEmru0tP+R+9f3f9cxAxA Sh8c/Q+LUHvBY7ED1ETg0LJp0ytPpeaaa1OpgfGKOPvp+sc8zfY8r4UwlEo6sIBiM/Wp bkunUMDZvJlmJteWwrUi5x1RJPzdBr7OSydanZM1ar9QwqjCmTSemzoPmgfgB1DKr4K3 y87qqxiYGsDCKKc2OC46HQprCOO4aJ0bfG5aYMchrP5BWhmYOLW0DiunejoWzRThBrmx wU4nsQmphYD1VqWxgMbjRqOcDtcX0seAURvoWgwkVHcuqfheq1HrF3BqBkPeMWdUJnrJ mNzw== X-Received: by 10.70.38.161 with SMTP id h1mr16926892pdk.97.1421353371143; Thu, 15 Jan 2015 12:22:51 -0800 (PST) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id a6sm2180989pbu.64.2015.01.15.12.22.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Jan 2015 12:22:50 -0800 (PST) Message-ID: <54B82198.8090204@gmail.com> Date: Thu, 15 Jan 2015 12:22:48 -0800 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-httpbis-http2.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------000907060304040501050105" Archived-At: Subject: [secdir] Secdir review of draft-ietf-httpbis-http2-16 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, 15 Jan 2015 20:22:54 -0000 This is a multi-part message in MIME format. --------------000907060304040501050105 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. I only had time to skim through the document but overall, the document is well written and appears to appropriately address the security concerns. I suggest that the document is READY for publication. Just as a "ni" (it's less than a "nit" ;-), should the list of prohibited cipher suites become an IANA registry? Doing so would make it easier to authoritatively add to it, and others may be interested in referencing the list. Best regards, Chris --------------000907060304040501050105 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.

I only had time to skim through the document but overall, the document is well written and appears to appropriately address the security concerns.  I suggest that the document is READY for publication.

Just as a "ni" (it's less than a "nit" ;-), should the list of prohibited cipher suites become an IANA registry?  Doing so would make it easier to authoritatively add to it, and others may be interested in referencing the list.

Best regards,
Chris
--------------000907060304040501050105-- From nobody Thu Jan 15 13:30:08 2015 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 19FA21A90CD; Thu, 15 Jan 2015 13:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gmWYVDMxGYP6; Thu, 15 Jan 2015 13:30:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471561A8993; Thu, 15 Jan 2015 13:29:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRJ91060; Thu, 15 Jan 2015 21:29:57 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 Jan 2015 21:29:57 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Thu, 15 Jan 2015 13:29:48 -0800 From: Leeyoung To: Warren Kumari , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHQLdwpi9kcjmRWWUyL0vaRwgDJ2pzBtVMQ Date: Thu, 15 Jan 2015 21:29:48 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C71F5E@dfweml706-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: DcPy Gjx2 IyHl JhFI MdHN O1Ll PB6N QH7z RISL TV6n c/gc d3eD jAS2 oSw4 ohcz rii0; 4; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGcAZQBuAGUAcgBhAGwALQBjAG8AbgBzAHQAcgBhAGkAbgB0AC0AZQBuAGMAbwBkAGUALgBhAGwAbABAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AGkAZQBzAGcAQABpAGUAdABmAC4AbwByAGcAOwBzAGUAYwBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA7AHcAYQByAHIAZQBuAEAAawB1AG0AYQByAGkALgBuAGUAdAA=; Sosha1_v1; 7; {670DBCAF-364A-4217-84B0-09F46A49422A}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 15 Jan 2015 21:29:39 GMT; UgBFADoAIABTAGUAYwBEAGkAcgAgAHIAZQB2AGkAZQB3ACAAbwBmACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGcAZQBuAGUAcgBhAGwALQBjAG8AbgBzAHQAcgBhAGkAbgB0AC0AZQBuAGMAbwBkAGUA x-cr-puzzleid: {670DBCAF-364A-4217-84B0-09F46A49422A} x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-ccamp-general-constraint-encode 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, 15 Jan 2015 21:30:02 -0000 SGkgV2FycmVuLA0KDQpUaGFua3MgZm9yIHlvdXIgdGhyb3VnaCByZXZpZXcgYW5kIGNvbW1lbnRz LiANCg0KSSB0aGluayBhbGwgeW91ciBjb21tZW50IGFyZSBhY2NlcHRhYmxlLiBQbGVhc2Ugc2Vl IGlubGluZSBmb3IgZGV0YWlscy4gDQoNClRoYW5rcywNCllvdW5nDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBXYXJyZW4gS3VtYXJpIFttYWlsdG86d2FycmVuQGt1bWFyaS5u ZXRdIA0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDExLCAyMDE1IDI6MjEgUE0NClRvOiBpZXNnQGll dGYub3JnOyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJh aW50LWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFNlY0RpciByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlDQoNCkJlIHllIG5vdCBh bGFybWVkLi4uDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhl IHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVU RiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KSUVTRy4gIFRoZXNlIGNvbW1lbnRz IHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0Kc2VjdXJpdHkg YXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRy ZWF0DQp0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy4NCg0KdGw7ZHI6IFJlYWR5IHdpdGggbml0cy4NCg0KU3VtbWFyeToNClRoaXMgZHJhZnQgY29u dGFpbnMgYSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgb24gZW5jb2RpbmcgbGFiZWwgYW5kDQpj b25uZWN0aXZpdHkgY29uc3RyYWludHMgb24gR01QTFMgY29udHJvbGxlZCBuZXR3b3Jrcy4gSXQg YWxzbyBoYXMNCnNvbWUgd2lja2VkIEFTQ0lJIGFydC4uLi4NCg0KSSdtIG5vdCByZWFsbHkgYSBH TVBMUyBwZXJzb24sIGFuZCBzbyBzb21lIG9mIHRoZSBjb25zdHJhaW50cyB0aGF0DQp0aGlzIGRp c2N1c3NlZCBoYWRuJ3QgcmVhbGx5IG9jY3VycmVkIHRvIG1lIChsaWtlIHNvbWUgZ2VhciBub3Qg YmVpbmcNCmFibGUgdG8gZG8gd2F2ZWxlbmd0aCBjb252ZXJzaW9uIC0tIGJ5IHRoZSB0aW1lIEkg c2VlIGEgbGluayBpdHMgaW4gYQ0Kcm91dGVyIDotKSkuIEFueXdheSwgdGhpcyBzZWVtIGxpa2Ug YSByZWFsIHByb2JsZW0sIGFuZCB0aGUgc29sdXRpb24NCnNlZW1zIHJlYXNvbmFibGUuDQpGcm9t IGEgc2VjdXJpdHkgc3RhbmRwb2ludCBJIGNvdWxkbid0IHJlYWxseSBzZWUgbXVjaCBpc3N1ZSBo ZXJlIC0tIEkNCmd1ZXNzIGEgc3VpdGFibHkgcGxhY2VkIGF0dGFja2VyIGNvdWxkIHNpZ25hbCBh ZGRpdGlvbmFsIGNvbnN0cmFpbnRzLA0KZWl0aGVyIGZvcmNpbmcgcGF0aHMgdG8gYmUgYnVpbHQg cGFzdCBhIHBsYWNlIHdoZXJlIGhlIGNvdWxkIGludGVyY2VwdA0KdGhlbSwgb3IgYWRkaW5nIGNv bnN0cmFpbnRzIHRoYXQgcHJldmVudCBwYXRocyBmcm9tIGJlaW5nIGJ1aWx0IGF0DQphbGwuIEFu IGF0dGFja2VyIHdpdGggdGhpcyBsZXZlbCBvZiBhY2Nlc3MgaGFzIGFscmVhZHkgd29uLCBhbmQg c28gSQ0KZG9uJ3QgdmlldyB0aGlzIGFzIGEgbWFqb3IgaXNzdWUuDQoNCkkgKmRvKiBob3dldmVy IGhhdmUgYSBwaWxlIG8nIG5pdHMsIHNlZSBiZWxvdywgaW4gQ09QRSAoQ29tbWVudCwNCk9yaWdp bmFsLCBQcm9wb3NlZCwgRXJyb3IpIGZvcm1hdC4gVGhlc2UgYXJlIGFsbCByZWFkYWJpbGl0eSAv DQpncmFtbWFyLCBubyBzdWJzdGFudGl2ZSBjaGFuZ2VzIGJlbG93Li4uLg0KDQpBYnN0cmFjdA0K DQogICBHZW5lcmFsaXplZCBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBjYW4gYmUgdXNl ZCB0byBjb250cm9sIGENCiAgIHdpZGUgdmFyaWV0eSBvZiB0ZWNobm9sb2dpZXMuIEluIHNvbWUg b2YgdGhlc2UgdGVjaG5vbG9naWVzIG5ldHdvcmsNCg0KW09dSW4gc29tZSBvZiB0aGVzZSB0ZWNo bm9sb2dpZXMgbmV0d29yaw0KDQpbUF0gSW4gc29tZSBvZiB0aGVzZSB0ZWNobm9sb2dpZXMsIG5l dHdvcmsNCg0KLy9ZT1VORy8vIE9LLiANCg0KW0NdIGdyYW1tYXINCg0KICAgZWxlbWVudHMgYW5k IGxpbmtzIG1heSBpbXBvc2UgYWRkaXRpb25hbCByb3V0aW5nIGNvbnN0cmFpbnRzIHN1Y2ggYXMN CiAgIGFzeW1tZXRyaWMgc3dpdGNoIGNvbm5lY3Rpdml0eSwgbm9uLWxvY2FsIGxhYmVsIGFzc2ln bm1lbnQsIGFuZA0KICAgbGFiZWwgcmFuZ2UgbGltaXRhdGlvbnMgb24gbGlua3MuDQoNCiAgWyBT TklQIF0NCg0KDQoNCiAgICAgMS4xLiBOb2RlIFN3aXRjaGluZyBBc3ltbWV0cnkgQ29uc3RyYWlu dHMNCg0KICAgRm9yIHNvbWUgbmV0d29yayBlbGVtZW50cyB0aGUgYWJpbGl0eSBvZiBhIHNpZ25h bCBvciBwYWNrZXQgb24gYQ0KDQpbT10gRm9yIHNvbWUgbmV0d29yayBlbGVtZW50cyB0aGUgYWJp bGl0eQ0KDQpbUF0gRm9yIHNvbWUgbmV0d29yayBlbGVtZW50cywgdGhlIGFiaWxpdHkNCg0KLy9Z T1VORy8vIE9LLiANCg0KW0NdIGdyYW1tYXIvcmVhZGFiaWxpdHkNCg0KICAgcGFydGljdWxhciBp bnB1dCBwb3J0IHRvIHJlYWNoIGEgcGFydGljdWxhciBvdXRwdXQgcG9ydCBtYXkgYmUNCiAgIGxp bWl0ZWQuIEluIGFkZGl0aW9uLCBpbiBzb21lIG5ldHdvcmsgZWxlbWVudHMgdGhlIGNvbm5lY3Rp dml0eQ0KICAgYmV0d2VlbiBzb21lIGlucHV0IHBvcnRzIGFuZCBvdXRwdXQgcG9ydHMgbWF5IGJl IGZpeGVkLCBlLmcuLCBhDQogICBzaW1wbGUgbXVsdGlwbGV4ZXIuIFRvIHRha2UgaW50byBhY2Nv dW50IHN1Y2ggY29uc3RyYWludHMgZHVyaW5nDQogICBwYXRoIGNvbXB1dGF0aW9uIHdlIG1vZGVs IHRoaXMgYXNwZWN0IG9mIGEgbmV0d29yayBlbGVtZW50IHZpYSBhDQoNCltPXSBwYXRoIGNvbXB1 dGF0aW9uIHdlIG1vZGVsDQoNCltQXSBwYXRoIGNvbXB1dGF0aW9uLCB3ZSBtb2RlbA0KDQovL1lP VU5HLy8gT0suIA0KDQpbQ10gZ3JhbW1hci9yZWFkYWJpbGl0eQ0KDQoNCg0KICAgY29ubmVjdGl2 aXR5IG1hdHJpeC4NCg0KICAgVGhlIGNvbm5lY3Rpdml0eSBtYXRyaXggKENvbm5lY3Rpdml0eU1h dHJpeCkgcmVwcmVzZW50cyBlaXRoZXIgdGhlDQogICBwb3RlbnRpYWwgY29ubmVjdGl2aXR5IG1h dHJpeCBmb3IgYXN5bW1ldHJpYyBzd2l0Y2hlcyBvciBmaXhlZA0KICAgY29ubmVjdGl2aXR5IGZv ciBhbiBhc3ltbWV0cmljIGRldmljZSBzdWNoIGFzIGEgbXVsdGlwbGV4ZXIuIE5vdGUNCiAgIHRo YXQgdGhpcyBtYXRyaXggZG9lcyBub3QgcmVwcmVzZW50IGFueSBwYXJ0aWN1bGFyIGludGVybmFs IGJsb2NraW5nDQogICBiZWhhdmlvciBidXQgaW5kaWNhdGVzIHdoaWNoIGlucHV0IHBvcnRzIGFu ZCBsYWJlbHMgKGUuZy4sDQogICB3YXZlbGVuZ3RocykgY291bGQgcG9zc2libHkgYmUgY29ubmVj dGVkIHRvIGEgcGFydGljdWxhciBvdXRwdXQgcG9ydA0KICAgYW5kIGxhYmVsIHBhaXIuIFJlcHJl c2VudGluZyBpbnRlcm5hbCBzdGF0ZSBkZXBlbmRlbnQgYmxvY2tpbmcgZm9yIGENCiAgIG5vZGUg aXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGFuZCBkdWUgdG8gaXQncyBoaWdo bHkNCiAgIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCBuYXR1cmUgd291bGQgbW9zdCBsaWtlbHkg bm90IGJlIHN1YmplY3QgdG8NCg0KW09dIGFuZCBkdWUgdG8gaXQncyBoaWdobHkgaW1wbGVtZW50 YXRpb24gZGVwZW5kZW50IG5hdHVyZSB3b3VsZCBtb3N0DQoNCltQXSBhbmQsIGR1ZSB0byBpdHMg aGlnaGx5IGltcGxlbWVudGF0aW9uLWRlcGVuZGVudCBuYXR1cmUsIHdvdWxkIG1vc3QNCg0KLy9Z T1VORy8vIE9LLiANCg0KW0NdIGFwb3N0cm9waGUgcmVtb3ZlZCBhbmQgdHdvIGNvbW1hcyBhZGRl ZDsgZ3JhbW1hci9yZWFkYWJpbGl0eQ0KDQogICBzdGFuZGFyZGl6YXRpb24gaW4gdGhlIGZ1dHVy ZS4gVGhlIGNvbm5lY3Rpdml0eSBtYXRyaXggaXMgYQ0KICAgY29uY2VwdHVhbCBNKm0gYnkgTipu IG1hdHJpeCB3aGVyZSBNIHJlcHJlc2VudHMgdGhlIG51bWJlciBvZiBpbnB1dA0KICAgcG9ydHMg ZWFjaCB3aXRoIG0gbGFiZWxzIGFuZCBOIHRoZSBudW1iZXIgb2Ygb3V0cHV0IHBvcnRzIGVhY2gg d2l0aA0KICAgbiBsYWJlbHMuDQoNCiAgICAgMS4yLiBOb24tTG9jYWwgTGFiZWwgQXNzaWdubWVu dCBDb25zdHJhaW50cw0KDQogICBJZiB0aGUgbmF0dXJlIG9mIHRoZSBlcXVpcG1lbnQgaW52b2x2 ZWQgaW4gYSBuZXR3b3JrIHJlc3VsdHMgaW4gYQ0KICAgcmVxdWlyZW1lbnQgZm9yIG5vbi1sb2Nh bCBsYWJlbCBhc3NpZ25tZW50IHdlIGNhbiBoYXZlIGNvbnN0cmFpbnRzDQoNCltPXSBmb3Igbm9u LWxvY2FsIGxhYmVsIGFzc2lnbm1lbnQgd2UgY2FuIGhhdmUNCg0KW1BdIGZvciBub24tbG9jYWwg bGFiZWwgYXNzaWdubWVudCwgd2UgY2FuIGhhdmUNCg0KLy9ZT1VORy8vIE9LLiANCg0KW0NdIGdy YW1tYXIvcmVhZGFiaWxpdHkNCg0KDQoNCiAgIGJhc2VkIG9uIGxpbWl0cyBpbXBvc2VkIGJ5IHRo ZSBwb3J0cyB0aGVtc2VsdmVzIGFuZCB0aG9zZSB0aGF0IGFyZQ0KICAgaW1wbGllZCBieSB0aGUg Y3VycmVudCBsYWJlbCB1c2FnZS4gTm90ZSB0aGF0IGNvbnN0cmFpbnRzIHN1Y2ggYXMNCiAgIHRo ZXNlIG9ubHkgYmVjb21lIGltcG9ydGFudCB3aGVuIGxhYmVsIGFzc2lnbm1lbnQgaGFzIGEgbm9u LWxvY2FsDQogICBjaGFyYWN0ZXIuIEZvciBleGFtcGxlIGluIE1QTFMgYW4gTFNSIG1heSBoYXZl IGEgbGltaXRlZCByYW5nZSBvZg0KICAgbGFiZWxzIGF2YWlsYWJsZSBmb3IgdXNlIG9uIGFuIG91 dHB1dCBwb3J0IGFuZCBhIHNldCBvZiBsYWJlbHMNCiAgIGFscmVhZHkgaW4gdXNlIG9uIHRoYXQg cG9ydCBhbmQgaGVuY2UgdW5hdmFpbGFibGUgZm9yIHVzZS4gVGhpcw0KDQpbT10gRm9yIGV4YW1w bGUgaW4gTVBMUyBhbiBMU1IgbWF5IGhhdmUgYSBsaW1pdGVkIHJhbmdlIG9mDQoNCiAgIGxhYmVs cyBhdmFpbGFibGUgZm9yIHVzZSBvbiBhbiBvdXRwdXQgcG9ydCBhbmQgYSBzZXQgb2YgbGFiZWxz DQogICBhbHJlYWR5IGluIHVzZSBvbiB0aGF0IHBvcnQgYW5kIGhlbmNlIHVuYXZhaWxhYmxlIGZv ciB1c2UuDQoNCltQXSBGb3IgZXhhbXBsZSwgaW4gTVBMUyBhbiBMU1IgbWF5IGhhdmUgYSBsaW1p dGVkIHJhbmdlIG9mIGxhYmVscw0KYXZhaWxhYmxlIGZvciB1c2Ugb24gYW4gb3V0cHV0IHBvcnQs IGFuZCBhIHNldCBvZiBsYWJlbHMNCg0KICAgYWxyZWFkeSBpbiB1c2Ugb24gdGhhdCBwb3J0LCBh bmQgaGVuY2UgdW5hdmFpbGFibGUgZm9yIHVzZS4NCg0KLy9ZT1VORy8vIE9LLiANCg0KW0NdIGdy YW1tYXIvcmVhZGFiaWxpdHkNCg0KDQogICBpbmZvcm1hdGlvbiwgaG93ZXZlciwgZG9lcyBub3Qg bmVlZCB0byBiZSBzaGFyZWQgdW5sZXNzIHRoZXJlIGlzDQogICBzb21lIGxpbWl0YXRpb24gb24g dGhlIExTUidzIGxhYmVsIHN3YXBwaW5nIGFiaWxpdHkuIEZvciBleGFtcGxlIGlmDQogICBhIFRE TSBub2RlIGxhY2tzIHRoZSBhYmlsaXR5IHRvIHBlcmZvcm0gdGltZS1zbG90IGludGVyY2hhbmdl IG9yIGENCiAgIFdTT04gbGFja3MgdGhlIGFiaWxpdHkgdG8gcGVyZm9ybSB3YXZlbGVuZ3RoIGNv bnZlcnNpb24gdGhlbiB0aGUNCiAgIGxhYmVsIGFzc2lnbm1lbnQgcHJvY2VzcyBpcyBub3QgbG9j YWwgdG8gYSBzaW5nbGUgbm9kZSBhbmQgaXQgbWF5IGJlDQogICBhZHZhbnRhZ2VvdXMgdG8gc2hh cmUgdGhlIGxhYmVsIGFzc2lnbm1lbnQgY29uc3RyYWludCBpbmZvcm1hdGlvbg0KICAgZm9yIHVz ZSBpbiBwYXRoIGNvbXB1dGF0aW9uLg0KDQpbT10gRm9yIGV4YW1wbGUgaWYNCg0KICAgYSBURE0g bm9kZSBsYWNrcyB0aGUgYWJpbGl0eSB0byBwZXJmb3JtIHRpbWUtc2xvdCBpbnRlcmNoYW5nZSBv ciBhDQogICBXU09OIGxhY2tzIHRoZSBhYmlsaXR5IHRvIHBlcmZvcm0gd2F2ZWxlbmd0aCBjb252 ZXJzaW9uIHRoZW4gdGhlDQogICBsYWJlbCBhc3NpZ25tZW50IHByb2Nlc3MgaXMgbm90IGxvY2Fs IHRvIGEgc2luZ2xlIG5vZGUgYW5kIGl0IG1heSBiZQ0KICAgYWR2YW50YWdlb3VzIHRvIHNoYXJl IHRoZSBsYWJlbCBhc3NpZ25tZW50IGNvbnN0cmFpbnQgaW5mb3JtYXRpb24NCiAgIGZvciB1c2Ug aW4gcGF0aCBjb21wdXRhdGlvbi4NCg0KW1BdIEZvciBleGFtcGxlLCBpZiBhIFRETSBub2RlIGxh Y2tzIHRoZSBhYmlsaXR5IHRvIHBlcmZvcm0gdGltZS1zbG90DQppbnRlcmNoYW5nZSwgb3IgYSBX U09OIGxhY2tzIHRoZSBhYmlsaXR5IHRvIHBlcmZvcm0gd2F2ZWxlbmd0aA0KY29udmVyc2lvbiwg dGhlbiB0aGUgbGFiZWwgYXNzaWdubWVudCBwcm9jZXNzIGlzIG5vdCBsb2NhbCB0byBhIHNpbmds ZQ0Kbm9kZS4gSW4gdGhpcyBjYXNlLCBpdCBpcyBtYXkgYmUgYWR2YW50YWdlb3VzIHRvIHNoYXJl IHRoZSBsYWJlbA0KYXNzaWdubWVudCBjb25zdHJhaW50IGluZm9ybWF0aW9uIGZvciB1c2UgaW4g cGF0aCBjb21wdXRhdGlvbi4NCg0KLy9ZT1VORy8vIE9LLiANCg0KW0NdIHJ1biBvbiBzZW50ZW5j ZTsgYnJva2VuIHVwIGFuZCBwdW5jdHVhdGVkIGZvciByZWFkYWJpbGl0eS4NCg0KICAgUG9ydCBs YWJlbCByZXN0cmljdGlvbnMgKFBvcnRMYWJlbFJlc3RyaWN0aW9uKSBtb2RlbCB0aGUgbGFiZWwN CiAgIHJlc3RyaWN0aW9ucyB0aGF0IHRoZSBuZXR3b3JrIGVsZW1lbnQgKG5vZGUpIGFuZCBsaW5r IG1heSBpbXBvc2Ugb24NCiAgIGEgcG9ydC4gVGhlc2UgcmVzdHJpY3Rpb25zIHRlbGwgdXMgd2hh dCBsYWJlbHMgbWF5IG9yIG1heSBub3QgYmUNCg0KDQoNClsgU05JUCBdDQoNCiAgIFRoZSBDb25u ZWN0aXZpdHkgTWF0cml4IEZpZWxkIHJlcHJlc2VudHMgaG93IGlucHV0IHBvcnRzIGFyZQ0KICAg Y29ubmVjdGVkIHRvIG91dHB1dCBwb3J0cyBmb3IgbmV0d29yayBlbGVtZW50cy4gVGhlIHN3aXRj aCBhbmQgZml4ZWQNCiAgIGNvbm5lY3Rpdml0eSBtYXRyaWNlcyBjYW4gYmUgY29tcGFjdGx5IHJl cHJlc2VudGVkIGluIHRlcm1zIG9mIGENCiAgIG1pbmltYWwgbGlzdCBvZiBpbnB1dCBhbmQgb3V0 cHV0IHBvcnQgc2V0IHBhaXJzIHRoYXQgaGF2ZSBtdXR1YWwNCiAgIGNvbm5lY3Rpdml0eS4gQXMg ZGVzY3JpYmVkIGluIFtTd2l0Y2hdIHN1Y2ggYSBtaW5pbWFsIGxpc3QNCg0KW09dIEFzIGRlc2Ny aWJlZCBpbiBbU3dpdGNoXSBzdWNoIGEgbWluaW1hbCBsaXN0DQoNCltQXSBBcyBkZXNjcmliZWQg aW4gW1N3aXRjaF0sIHN1Y2ggYSBtaW5pbWFsIGxpc3QNCg0KLy9ZT1VORy8vIE9LLiANCg0KW0Nd IGdyYW1tYXIvcmVhZGFiaWxpdHkNCg0KICAgcmVwcmVzZW50YXRpb24gbGVhZHMgbmF0dXJhbGx5 IHRvIGEgZ3JhcGggcmVwcmVzZW50YXRpb24gZm9yIHBhdGgNCiAgIGNvbXB1dGF0aW9uIHB1cnBv c2VzIHRoYXQgaW52b2x2ZXMgdGhlIGZld2VzdCBhZGRpdGlvbmFsIG5vZGVzIGFuZA0KICAgbGlu a3MuDQoNCiBbU05JUF0NCg0KICAgbyAgTGluayBTZXQgQSBkaXI9aW5wdXQsIExpbmsgU2V0IEIg ZGlyPW91dHB1dA0KDQogICAgIFRoZSBtZWFuaW5nIG9mIHRoZSBwYWlyIG9mIGxpbmsgc2V0cyBB IGFuZCBCIGluIHRoaXMgY2FzZSBpcyB0aGF0DQogICAgIGFueSBzaWduYWwgdGhhdCBpbnB1dHMg YSBsaW5rIGluIHNldCBBIGNhbiBiZSBwb3RlbnRpYWxseSBzd2l0Y2hlZA0KICAgICBvdXQgb2Yg YW4gb3V0cHV0IGxpbmsgaW4gc2V0IEIuDQoNCltPXSAgVGhlIG1lYW5pbmcgb2YgdGhlIHBhaXIg b2YgbGluayBzZXRzIEEgYW5kIEIgaW4gdGhpcyBjYXNlIGlzIHRoYXQNCg0KICAgICBhbnkgc2ln bmFsIHRoYXQgaW5wdXRzIGEgbGluayBpbiBzZXQgQSBjYW4gYmUgcG90ZW50aWFsbHkgc3dpdGNo ZWQNCiAgICAgb3V0IG9mIGFuIG91dHB1dCBsaW5rIGluIHNldCBCLg0KDQpbUF0gSW4gdGhpcyBj YXNlLCB0aGUgbWVhbmluZyBvZiB0aGUgcGFpciBvZiBsaW5rIHNldHMgQSBhbmQgQiBpcyB0aGF0 DQphbnkgc2lnbmFsIHRoYXQgaW5wdXRzIGEgbGluayBpbiBzZXQgQSBjYW4gYmUgcG90ZW50aWFs bHkgc3dpdGNoZWQgb3V0DQpvZiBhbiBvdXRwdXQgbGluayBpbiBzZXQgQi4NCg0KLy9ZT1VORy8v IE9LLiANCg0KW0NdIHJlYWRhYmlsaXR5DQoNCiAgIG8gIExpbmsgU2V0IEEgZGlyPWJpZGlyZWN0 aW9uYWwsIExpbmsgU2V0IEIgZGlyPWJpZGlyZWN0aW9uYWwNCg0KDQpbU05JUF0NCg0KICAgVGhl IHBvcnQgbGFiZWwgcmVzdHJpY3Rpb24gY2FuIGJlIGVuY29kZWQgYXMgZm9sbG93czogTW9yZSB0 aGFuIG9uZQ0KICAgb2YgdGhlc2UgZmllbGRzIG1heSBiZSBuZWVkZWQgdG8gZnVsbHkgc3BlY2lm eSBhIGNvbXBsZXggcG9ydA0KICAgY29uc3RyYWludC4gV2hlbiBtb3JlIHRoYW4gb25lIG9mIHRo ZXNlIGZpZWxkcyBhcmUgcHJlc2VudCB0aGUNCg0KW09dIFdoZW4gbW9yZSB0aGFuIG9uZSBvZiB0 aGVzZSBmaWVsZHMgYXJlIHByZXNlbnQgdGhlDQoNCltQXSBXaGVuIG1vcmUgdGhhbiBvbmUgb2Yg dGhlc2UgZmllbGRzIGFyZSBwcmVzZW50LCB0aGUNCg0KLy9ZT1VORy8vIE9LLiANCg0KW0NdIGdy YW1tYXINCg0KICAgcmVzdWx0aW5nIHJlc3RyaWN0aW9uIGlzIHRoZSB1bmlvbiBvZiB0aGUgcmVz dHJpY3Rpb25zIGV4cHJlc3NlZCBpbg0KICAgZWFjaCBmaWVsZC4gVG8gaW5kaWNhdGUgdGhhdCBh IHJlc3RyaWN0aW9uIGFwcGxpZXMgdG8gdGhlIHBvcnQgaW4NCiAgIGdlbmVyYWwgYW5kIG5vdCB0 byBhIHNwZWNpZmljIGNvbm5lY3Rpdml0eSBtYXRyaXggdXNlIHRoZSByZXNlcnZlZA0KICAgdmFs dWUgb2YgMHhGRiBmb3IgdGhlIE1hdHJpeElELg0KDQoNCltPXSBUbyBpbmRpY2F0ZSB0aGF0IGEg cmVzdHJpY3Rpb24gYXBwbGllcyB0byB0aGUgcG9ydCBpbg0KDQogICBnZW5lcmFsIGFuZCBub3Qg dG8gYSBzcGVjaWZpYyBjb25uZWN0aXZpdHkgbWF0cml4IHVzZSB0aGUgcmVzZXJ2ZWQNCiAgIHZh bHVlIG9mIDB4RkYgZm9yIHRoZSBNYXRyaXhJRC4NCg0KW1BdIFVzZSB0aGUgcmVzZXJ2ZWQgdmFs dWUgb2YgMHhGRiBmb3IgdGhlIE1hdHJpeElEIHRvIGluZGljYXRlIHRoYXQgYQ0KcmVzdHJpY3Rp b24gYXBwbGllcyB0byB0aGUgcG9ydC4NCg0KLy9ZT1VORy8vIE9LLiANCg0KW0NdIGdyYW1tYXIv cmVhZGFiaWxpdHkNCg0KDQogICBbQklHIFNOSVBdDQoNCg0KDQoNCjMuIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBwcm90b2NvbC1pbmRlcGVuZGVu dCBlbmNvZGluZ3MgZm9yIFdTT04NCiAgIGluZm9ybWF0aW9uIGFuZCBkb2VzIG5vdCBpbnRyb2R1 Y2UgYW55IHNlY3VyaXR5IGlzc3Vlcy4NCg0KICAgSG93ZXZlciwgb3RoZXIgZG9jdW1lbnRzIHRo YXQgbWFrZSB1c2Ugb2YgdGhlc2UgZW5jb2RpbmdzIHdpdGhpbg0KICAgcHJvdG9jb2wgZXh0ZW5z aW9ucyBuZWVkIHRvIGNvbnNpZGVyIHRoZSBpc3N1ZXMgYW5kIHJpc2tzIGFzc29jaWF0ZWQNCg0K DQoNCkJlcm5zdGVpbiBhbmQgTGVlICAgICAgIEV4cGlyZXMgSnVuZSAyOSwgMjAxNSAgICAgICAg ICAgICAgICAgW1BhZ2UgMTddDQoNCkludGVybmV0LURyYWZ0IEdlbmVyYWwgTmV0d29yayBFbGVt ZW50IENvbnN0cmFpbnQgRW5jb2RpbmcgRGVjZW1iZXINCjIwMTQNCg0KDQogICB3aXRoLCBpbnNw ZWN0aW9uLCBpbnRlcmNlcHRpb24sIG1vZGlmaWNhdGlvbiwgb3Igc3Bvb2Zpbmcgb2YgYW55IG9m DQoNCltPXSAgd2l0aCwgaW5zcGVjdGlvbg0KDQpbUF0gd2l0aCBpbnNwZWN0aW9uDQoNCi8vWU9V TkcvLyBPSy4NCg0KW1JdIG5vIGNvbW1hIG5lZWRlZA0KDQoNCg0KDQotLSANCkkgZG9uJ3QgdGhp bmsgdGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQN CmlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vh c2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZw0KcmVncmV0IGF0IGhhdmlu ZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBhaXINCm9m IHBhbnRzLg0KICAgLS0tbWFmDQo= From nobody Thu Jan 15 15:32:09 2015 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 A3A6F1A908E; Thu, 15 Jan 2015 15:32:08 -0800 (PST) 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 VWKSWT8vK0u5; Thu, 15 Jan 2015 15:32:07 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2591A9089; Thu, 15 Jan 2015 15:32:07 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id va2so6371583obc.2; Thu, 15 Jan 2015 15:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7YDmFxMl2Yk9LaPGxCiGvkbJRGLKykPAPZSn7x1yftU=; b=ucNKEbDZaCtiWp/rcwmH5f0tx2brJwjtz1hi+HLvOtmGQ0WxvIr5aSv3XVQupYXPbM aWxdTj0frxIrzK7rZr61uYall0Tj2TXLwRAQ7IRqz/C+YMp8JFpva54iJM7trd8u4cUD uxgCZJgcB70QK2DY1QUGqtDMwaEkgzRfpK/lssd1JqB9TtfUIwXmnh3vBKsdlCAy44/t X0uFk7WVgCFuR3go8qzLpCOeGMuH92Mzdwm0Vj88Wie7Vy4yN+EC70W6MX2rfQEREw+t j5zEp4ddUnebV2gHHz92+CJ8L2wtcCqv8kgZLjRpySYk9GEw874cK/D24rRcZb2Y7fHr LbTA== MIME-Version: 1.0 X-Received: by 10.60.146.231 with SMTP id tf7mr7637131oeb.48.1421364726391; Thu, 15 Jan 2015 15:32:06 -0800 (PST) Received: by 10.202.226.136 with HTTP; Thu, 15 Jan 2015 15:32:06 -0800 (PST) In-Reply-To: <54B82198.8090204@gmail.com> References: <54B82198.8090204@gmail.com> Date: Thu, 15 Jan 2015 15:32:06 -0800 Message-ID: From: Martin Thomson To: Chris Lonvick Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-httpbis-http2.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-http2-16 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, 15 Jan 2015 23:32:08 -0000 On 15 January 2015 at 12:22, Chris Lonvick wrote: > Just as a "ni" (it's less than a "nit" ;-), should the list of prohibited > cipher suites become an IANA registry? Doing so would make it easier to > authoritatively add to it, and others may be interested in referencing the > list. We can't add to the list. If we did that, we would create the potential for disagreement between peers about what can generate "INADEQUATE_SECURITY" and what cannot. The document is therefore the best place for the list. From nobody Fri Jan 16 14:34:33 2015 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 8D65E1A8A42; Fri, 16 Jan 2015 14:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 PYKWcGPXZ0Ez; Fri, 16 Jan 2015 14:34:29 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E436F1A8A1D; Fri, 16 Jan 2015 14:34:28 -0800 (PST) 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 t0GMW9cv024623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Jan 2015 17:32:09 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_9672573D-D05F-4912-B661-16758F93DB3A" Date: Fri, 16 Jan 2015 17:32:09 -0500 Message-Id: <27B7DBED-C921-45C3-8761-3C26D3FA13D8@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-l2vpn-pbb-evpn.all@tools.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] secdir review of draft-ietf-12vpn-pbb-evpn-09 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, 16 Jan 2015 22:34:31 -0000 --Apple-Mail=_9672573D-D05F-4912-B661-16758F93DB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 describes a method for integrating Ethernet Provider Backbone = Bridge (PBB) with Ethernet VPN (EVPN) to improve the delivery of MAC addresses, in particular with respect to = scalability. =20 I don=92t see any security concerns with this draft, but I do have some = comments on the Security Considerations section. It is very short, and all it says that the security considerations in = the EVPN draft apply directly to this draft. I assume that it is also the case that this draft introduces no new security = considerations. If so, you should say so, and you should also say why. Also, I was wondering if the mechanisms introduced in = this draft, by introducing a greater degree of organization in the delivery of MAC addresses, makes it easier to detect duplicated = MACs, which were mentioned as a security risk in the Security Considerations of the EVPN draft. If this is the case, it = would be a good thing to mention here. I=92d consider the draft somewhere between ready with nits and ready = with issues. I don=92t see any real security issues here, just a Security Considerations section that needs to be expanded a = little, but this seems to be a little more than what the secdir guidelines would call a nit. Cathy Meadows =20 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=_9672573D-D05F-4912-B661-16758F93DB3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

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 draft describes a method for = integrating Ethernet Provider Backbone Bridge (PBB) with Ethernet VPN = (EVPN) to
improve the delivery of MAC addresses, in particular with = respect to scalability.  

I don=92t see = any security concerns with this draft, but I do have some comments on = the Security Considerations section.
It is very short, and all = it says that the security considerations in the EVPN draft apply = directly to this draft. I assume that
it is also the case that = this draft introduces no new security considerations.  If so, you = should say so, and you should
also say why.  Also, I was = wondering if the mechanisms introduced in this draft, by introducing a = greater degree of organization
in the delivery of MAC = addresses, makes it easier to detect duplicated MACs, which were = mentioned as a security risk in the
Security Considerations of = the EVPN draft.  If this is the case, it would be a good thing to = mention here.

I=92d consider the draft = somewhere between ready with nits and ready with issues.  I don=92t = see any real security issues
here, just a Security = Considerations section that needs to be expanded a little, but this = seems to be a little more than what the
secdir guidelines = would call a nit.

Cathy = Meadows

 
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=_9672573D-D05F-4912-B661-16758F93DB3A-- From nobody Sat Jan 17 09:00:50 2015 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 E29E01ACE7B; Sat, 17 Jan 2015 09:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, 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 Ri0G0Bxs5oq4; Sat, 17 Jan 2015 09:00:38 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1C31ACE71; Sat, 17 Jan 2015 09:00:37 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0HH0Zi3006957; Sat, 17 Jan 2015 17:00:35 GMT Received: from 950129200 (80-121-133-160.adsl.highway.telekom.at [80.121.133.160]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0HH0X4r006937 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 17 Jan 2015 17:00:33 GMT From: "Adrian Farrel" To: "'Catherine Meadows'" , , , Date: Sat, 17 Jan 2015 17:00:33 -0000 Message-ID: <06af01d03277$1c3421e0$549c65a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B0_01D03277.1C4ADE30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAydxp23s1ZdmfGSdynkv0Qges2oQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21260.000 X-TM-AS-Result: No--16.420-10.0-31-10 X-imss-scan-details: No--16.420-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wpVRzPxemJL0R0SX1OwlZFo4YKAM3oRt9mn7 AlTb8W2xmbgtFJbseiaV2J8ChOmkcy3WqVyn1cYBGAZMT5SLmAm4fXb7uySbzLy37eagx/pvrJD z6eZqMHYMlKaC3KZu2GOGs1uLOfcTF9xhZeaQOFUdxBAG5/hkW8MdI0UcXEHz67U1wiTxyXlDrM KVfV1MUnWE2glTdWtcxckmBxoBooptNLAj8DYO8GOho7buv7d94B7aueLmU0AJW4Re2U2py7E+h khRyJ1VOQkvNhjaeOVrGYgnc86ReRP2tmfV1UdzsFkCLeeufNsNgFUqZt55A5pQzIv0XTM8oKjh CxtQoO822uoEm245fkFWCvm86w840sXpjQvtH9B3vIzA7XyIiCEF1RdqrHVdtdx2lXHjF1Ii/B2 gujrEHzB6EdCmNDGVVbEDP0uzojXyTBeqcpWTVlRe8joruKtpIFb2VdwQdkDROhK+RFWo5lthOg NFYwZakNCK/RB7QjECSHHGjA3FAhfyTevQtfkQkdcpJKX5Jwr8BlbXy+O/WnKuL8SC59l3YCowK SvpI+95QzetarMsxEgF6uuiHQ769Z8q6rO+Ih6Ycl4BgqVyk3cF/0kiqyh4DxjBugJBzzyS21KK zy8r6aJ3RIkxSexf0xDOrcQ7AZwh3ud9DyO68BIMDPFEv6Uxf6/Md8Lb2l8no0smd1GLZADH+SZ FBrRqJIPFmqDDlsqSU848M/hs6Ei8wUMZL0vvi+m1DDPm2yL/fHyH+MCF5RUZTfM00s4+akcq2R AHKcoguuCAVXi57q5R9aoXimHApwl9Ih7YezSeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMphuwoOnPhKbFW9RPK59Z/uIWOFdm04oIBtgm2FaYSOR+3BndfXUhXQ== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-l2vpn-pbb-evpn-09 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: Sat, 17 Jan 2015 17:00:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06B0_01D03277.1C4ADE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Cathy, [Note tweak to subject line to capture draft name] adrian From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Catherine Meadows Sent: 16 January 2015 22:32 To: secdir@ietf.org; iesg@ietf.org; draft-ietf-l2vpn-pbb-evpn.all@tools.org Cc: Catherine Meadows Subject: secdir review of draft-ietf-12vpn-pbb-evpn-09 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 draft describes a method for integrating Ethernet Provider Backbone Bridge (PBB) with Ethernet VPN (EVPN) to improve the delivery of MAC addresses, in particular with respect to scalability. I don't see any security concerns with this draft, but I do have some comments on the Security Considerations section. It is very short, and all it says that the security considerations in the EVPN draft apply directly to this draft. I assume that it is also the case that this draft introduces no new security considerations. If so, you should say so, and you should also say why. Also, I was wondering if the mechanisms introduced in this draft, by introducing a greater degree of organization in the delivery of MAC addresses, makes it easier to detect duplicated MACs, which were mentioned as a security risk in the Security Considerations of the EVPN draft. If this is the case, it would be a good thing to mention here. I'd consider the draft somewhere between ready with nits and ready with issues. I don't see any real security issues here, just a Security Considerations section that needs to be expanded a little, but this seems to be a little more than what the secdir guidelines would call a nit. Cathy Meadows 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 ------=_NextPart_000_06B0_01D03277.1C4ADE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks = Cathy,

 

[Note tweak to subject line to = capture draft name]

 

adrian

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Catherine = Meadows
Sent: 16 January 2015 22:32
To: = secdir@ietf.org; iesg@ietf.org; = draft-ietf-l2vpn-pbb-evpn.all@tools.org
Cc: Catherine = Meadows
Subject: secdir review of = draft-ietf-12vpn-pbb-evpn-09

 

 

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 draft describes = a method for integrating Ethernet Provider Backbone Bridge (PBB) with = Ethernet VPN (EVPN) to

improve the delivery of MAC addresses, in particular with = respect to scalability.  

 

I don’t see any security concerns with this draft, but I = do have some comments on the Security Considerations = section.

It is very short, = and all it says that the security considerations in the EVPN draft apply = directly to this draft. I assume that

it is also the case that this draft introduces no new security = considerations.  If so, you should say so, and you = should

also say why. =  Also, I was wondering if the mechanisms introduced in this draft, = by introducing a greater degree of = organization

in the delivery of = MAC addresses, makes it easier to detect duplicated MACs, which were = mentioned as a security risk in the

Security Considerations of the EVPN draft.  If this is the = case, it would be a good thing to mention = here.

 

I’d consider the draft somewhere between ready with nits = and ready with issues.  I don’t see any real security = issues

here, just a = Security Considerations section that needs to be expanded a little, but = this seems to be a little more than what = the

secdir guidelines = would call a nit.

 

Cathy Meadows

 

 

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

 

------=_NextPart_000_06B0_01D03277.1C4ADE30-- From nobody Sat Jan 17 10:39:22 2015 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 2E9771ACECF; Sat, 17 Jan 2015 10:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 xmLlNBzFG_K4; Sat, 17 Jan 2015 10:39:14 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62F31AC3AC; Sat, 17 Jan 2015 10:39:11 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-25-54baab03db96 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.12.03326.30BAAB45; Sat, 17 Jan 2015 13:33:39 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t0HIXcAu007036; Sat, 17 Jan 2015 13:33:39 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0HIXW7Z004835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Jan 2015 13:33:36 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0HIXVg0002656; Sat, 17 Jan 2015 13:33:31 -0500 (EST) Date: Sat, 17 Jan 2015 13:33:31 -0500 (EST) From: Benjamin Kaduk To: "Paul Quinn (paulq)" In-Reply-To: <8C00C887-4A6A-481F-A472-6081FD4DC895@cisco.com> Message-ID: References: <8C00C887-4A6A-481F-A472-6081FD4DC895@cisco.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1969023811-1421344152=:23489" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLKsWRmVeSWpSXmKPExsUixG6nosu8eleIwd+/VhZvv9xjt5jxZyKz xcdTb5gs9r9aymrxYeFDFouHky+xO7B5TPm9kdVjyZKfTB7npnxn9Nj6ZAm7x5fLn9kCWKO4 bFJSczLLUov07RK4MhYfEi5Y38hY0f3nP0sD46W0LkZODgkBE4n/jZcZIWwxiQv31rN1MXJx CAksZpI4O6efFcLZyChx4fdlVpAqIYFDTBIXZ0RCJBoYJRrmH2YGSbAIaEs8+PqHCcRmE1CR mPlmIxuILSKgJXH712YWkAZmgXVMEm+OfgGbJCzgKPH8MITNKWArMeHLZbBBvEDx7n1nWCC2 FUk0L5gNZosK6Eis3j+FBaJGUOLkzCdgNrNAoMSmg8uhbEeJLy2XGScwCs1CUjYLSdksJGUQ trrEgU8XoWxtifs329hgahrnbWBZwMi2ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdYLzezRC81 pXQTIyjWOCX5djB+Pah0iFGAg1GJh5fjx84QIdbEsuLK3EOMkhxMSqK8y2fvChHiS8pPqcxI LM6ILyrNSS0+xCjBwawkwns8HSjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgm K8PBoSTBq7McqFGwKDU9tSItM6cEIc3EwQkynAdo+L9lIMOLCxJzizPTIfKnGBWlxHljQJoF QBIZpXlwvbBU+IpRHOgVYV5tkCoeYBqF634FNJgJaHD+4x0gg0sSEVJSDYzS6wRv9j5j/ppo /uoNs0bZPSP2XcmTn5jn3Ai13HY35kaNWEXp4rLbkhevrnpu6/klusYkVGZ7p60gT4bnzLNh f07PvnIkoD/2XE32jatbisKUdedcj6peXueTelTP2OdWejz3r3cztmxl3Nud9jVrS37IOZ13 a/c3eRl1yEldn7hBZbkbj40SS3FGoqEWc1FxIgDn9GHZYAMAAA== Archived-At: Cc: "tnadeau@lucidvision.com" , "Joel M. Halpern" , "draft-ietf-sfc-problem-statement.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-sfc-problem-statement-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: Sat, 17 Jan 2015 18:39:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1969023811-1421344152=:23489 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Mon, 12 Jan 2015, Paul Quinn (paulq) wrote: > Ben, > > Thank you for your detailed review and sorry for the delayed reply due > to the holidays. Understood. > I added some comments inline below. I=E2=80=99ve also cc=E2=80=99d our d= ocument > shepherd, Joel, since I=E2=80=99m not sure he was on the original distrib= ution. Thanks. I'll reply inline and trim unneeded bits... > > On Jan 2, 2015, at 7:39 PM, Benjamin Kaduk wrote: > > > > Hi all, > > > > Here are the potential security considerations I came up with so far: > > > > * An error in service classification could lead to untrusted traffic > > flowing through a service function chain intended for trusted traffic > > only. In various hypothetical situations, this could lead to an attack= er > > being able to execute privileged actions via a trusted service, execute= a > > DoS attack against an internal service, etc. It is important for servi= ce > > classification to "fail safe" to avoid this class of issues. ("Failing > > safe" might or might not include just dropping such traffic.) > > PQ> This statement applies to all things that depend on classification, > or configuration in general. Perhaps a statement about =E2=80=9Crisk ass= ociated > with configuration or other operational errors=E2=80=9D and service chain= ing > would help clarify. Yes, it is a very broad concern. The main point is to mention the general concern in this document, so that it is kept in mind as more concrete proposals are being made. I think that the sort of statement you propose could suffice, but would probably need to see the actual statement to be sure. > > * Similarly, errors in translating from an existing network/service > > topology to a separate service overlay (e.g., omission or addition of a > > firewall element) could lead to an attacker sending traffic in the real > > network to services which ought to be disallowed by the service overlay= =2E > > PQ> The above suggested statement (or something similar) would cover thi= s as well. Yes. There are lots of ways that traffic could end up where it's not supposed to; my bullet points are just an attempt to enumerate some of those ways, with the hope that being enumerated will make them less likely to be problems in actual operation. > > * The dataplane metadata could open up a giant rabbit hole of informati= on > > leakage. It is tempting to say that the metadata would only flow insid= e > > the network boundaries of a single (corporate) entity, but "SSL added a= nd > > removed here :-)" should convince us that that's not a workable solutio= n. > > Metadata could conceivably include the type of traffic, client informat= ion > > (i.e., personally identifying information), and more, some of which sho= uld > > receive protection from eavesdroppers on the dataplane which will not n= eed > > to process the traffic in question. > > PQ> The =E2=80=9Cvalue=E2=80=9D of the metadata is highly variable, in so= me > environments, as you point out, it might be sensitive. Perhaps we can > add the following to the security considerations sections: > > 1. If data plane confidentiality or integrity is required, a transport > that supports the requisite functionality (e.g. IPSec) should be used to > create the service overlay. Maybe even SHOULD? > 2. Similarly, control plane messages may be authenticated or encrypted, > as required by an operator, using existing mechanisms (e.g. SSL) It's probably better to say TLS than SSL. I think these additions would address my concerns in this area. > > > > * Metadata can come from "external sources". Those sources should be > > trustworthy and verified, or attackers could send traffic where they > > oughtn't be able to. > > PQ> Covered by the above control plane text. I'm not sure. This probably just means that I don't fully understand how the external sources would be providing metadata -- if it inherently must flow over the control plane, then sure, it's covered by the above text. > > Here's the grammar and language issues that bothered me, roughly sorted > > with the more important ones coming first and otherwise in order of > > appearance: > > > > Section 3 has the text "the SFC working group will [...]", which seems > > more appropriate for a WG charter than an informational RFC. I see thi= s > > had been brought up in discussion of the -03, but I did not see any > > obvious resolution in a quick skim. To be clear, I would be fine with > > something that didn't explicitly say what the WG would do, like "SFC ma= y > > include solutions utilizing the following elements" or something simila= r. > > PQ> The complete current version states: =E2=80=9C...will investigate sol= utions > that address the following elements:..=E2=80=9D which was widely reviewed= and > accepted the WG members. I'm not objecting to the specific things to be done. My point is very close to what Barry put in his COMMENT: there's no need to publish an RFC to say that "WG X will do thing Y" (that's what a charter is for) -- WG X should just do thing Y. It can, however, be useful to publish an RFC saying that "WG X has investigated the issue and concluded that thing Y should be done", and I would prefer that this document was worded in such a fashion. That is, I would prefer to replace "Concretely, the SFC working group will investigate solutions" with "Solutions should be investigated". But, as for Barry, it is not my place to block the document on this point. I have noted that it seems weird to me, and will not object if you go forward with it. > > The document uses some acronyms that are not expanded. I expect most > > readers to be familiar with some, but not all, of: > > * Open Systems Interconnection > > * the OSI model, e.g., layer 3, layer 7, etc. (I had to think a moment > > about "L4-L7") > > * transmission control protocol > > * Virtual Local Area Network > > * Border Gateway Protocol > > * internet protocol > > * virtual private network > > * multiprotocol label switching > > * Wide Area Network > > * datacenter > > PQ> As you point out, many of these are well known terms to readers of > the draft, as was the case with the reviewers. Yup. Barry was kind enough to point out the RFC Editor's list of acceptable acronyms (https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt), so there is only potential concern about the individual OSI layers and "DC" for datacenter. I'm sorry I didn't know about that list in advance to save the trouble. > > I can't find a parse that I'm happy with of the first paragraph of sect= ion > > 3.3. In particular, I'm not sure whether the leading "As such" is just= a > > transition leading into a new sentence (equivalent to "Thus,"), in whic= h > > case it should be offset by a comma, or if the "such" binds to "metadat= a" > > (equiavent to "Since such"). In the first version, I guess the metadat= a > > is supposed to be sent out-of-band and interpreted by functions along t= he > > service overlay, but I don't see how it would then *not* be used to > > control the route by which packets travel. In the latter version, the > > sentence is incomplete, since there's no dependent clause. > > > > PQ> As such does not mean =E2=80=9Cthus=E2=80=9D, thus (;-)) the sentence= can read: > > "As such it is not used as forwarding information to deliver packets > along the service overlay." Okay, that is enough for me to disambiguate. I very strongly suggest that you put a comma after "such". > Having said that, it=E2=80=99s pretty minor point, and can be fixed sever= al ways > if reader find it confusing/offensive: > > - I believe the correct use of =E2=80=9Cas such=E2=80=9D in this context = is to remove > the word metadata immediately following =E2=80=9Cas such=E2=80=9D. > - As such =E2=80=94> Metadata (i.e. remove as such) Well, replacing it with "it" instead of just removing it. That would work for me, though I think I would prefer "As such, this metadata [...]". I still don't see how (e.g.) antecedent classification is not used as forwarding information for (overlay-level) packet delivery, but am willing to take your word for it. > > The abstract uses the phrase "ordered set of instances", but a set is > > explicitly unordered. Is there a better term to use, like "graph", > > "network", or "structure"? (The word "set" also appears in the second > > paragraph of the abstract, but may be more appropriate in that usage.) > > > PQ> Is there not a concept of an ordered set as well? In formal mathematics, not exactly. If you have a full order relation for any pair of elements, then it is just an ordered list (or sequence). You can also have a partial order, where any given pair of elements might not be comparable; this sort of thing produces more interesting mathematics because there are more possibilities than just a fully ordered list. Anyway, this is not a formal mathematical setting, so you're probably fine leaving it as-is; I just wanted to ask whether "graph" or "network" would be more elucidating terms to use. In particular, the reader (me) wants to know if the order is a full order or a partial order -- saying that it is a list would make clear that it is a full order, and a graph or network is more likely to correspond to a partial order. > > I'm not sure I'm interpreting the third paragraph of section 2.1 correc= tly > > -- is the issue that the network topology needs to change in front and > > behind of each service function, whenever a new service function is > > required? Or is it that the network topology must change before and af= ter > > a new service function is introduced, in order to allow inserting the > > function without loss of serice? I would also find the last sentence m= ore > > clear if reorderd to be "[...] all traffic often passes through the sam= e > > strict order, whether a given service needs to be applied or not.=E2=80= =9D > > PQ> In many cases, both. But the intent here is to describe the =E2=80= =9Cfront=E2=80=9D > and =E2=80=9Cbehind=E2=80=9D issue. Okay. I think that is the way I interpret the current text, which is good. But using "front" and "behind" might make things more clear. > > In section 2.3, I don't understand what "constrained service function h= igh > > availability" is. Is the issue just that the topology forces a situati= on > > which could be subject to reduced availability because certain > > high-availability techniques are not usable in that topology? > > PQ> Correct, as described in the next paragraph: > > "Since traffic reaches many service functions based on network > topology, alternate, or redundant service functions must be placed in > the same topology as the primary service." It might be more clear if this was described as "constraints on" service function high availability. Your call. > > The second paragraph of the abstract is hard to parse; my best effort a= t > > cleaning it up is "The set of enabled service function chains reflects = the > > service offerings of a given operator, and is designed in conjunction w= ith > > application delivery, service, and network policy.", but I fear that ha= s > > changed the meaning somehow. ("chains" needs to be plural, as does > > "reflects", but there's also a missing article for "operator service > > offerings", and the two "ands" in the final clause read oddly.) > > > PQ> I=E2=80=99m not sure what is hard to parse, it seemed well understood= by the > WG members. Since WG members are (apparently) the main audience for this document I should probably leave it alone, then. Well, I would still s/reflect/reflects/ to get singular/plural agreement. Looking at it again, I think most of what confused me was the "X and Y and Z" construct, for which I may not have picked the right grouping the first time around. > > The definition for "classification" doesn't seem grammatical. Perhaps, > > "Locally instantiated policy to match traffic flows to the appropriate > > outbound action(s)"? Additionally, should the definition be explicitly > > constrained to just forwarding actions (my proposal is not)? > > PQ> This is the definition that WG come up with after several rounds off > back and forth (it=E2=80=99s used in other SFC drafts). We tried to keep= it > generic, rather than constrained. I think the main thing that feels odd to me is that the subject of the sentence (in a sentence classification sense) is the policy, whereas I would naively expect the matching to be the main thing involved in classification. The naive resolution to this issue would be to reorder things, as "Matching of traffic flows as a result of locally instantiated policy for identification of appropriate outbound forwarding actions". This does not trip my "feels weird" sense, so I think I have found the precise nature of my concern. I understand that the WG spent a lot of time coming up with this definition, so I won't insist on any changes; I will just note that there are potential grammar issues with it. > > In the definition for "service function", is "One of" needed? Also, > > s/the Service Function/a Service Function/ in the last sentence of the > > first paragraph. In the second paragraph, there's no need to say "etc.= " > > when prefaced with "includes:" -- just say "and TCP optimization" (note > > s/optimizer/optimization/ for tense consistency). > > PQ> Did you mean =E2=80=9COne or=E2=80=9D? If so, then yes. I did not mean "One or". I refer to the sentence "One of multiple Service Functions can be embedded in the same network element." I do not see an occurrence of "One or" in the definition of "Service Function". Ah, perhaps this is just a typo; that sentence does make more sense with "One or" instead of "One of" (but "more" is I think more common than "multiple" to follow it in this usage). > > The definition for "Service Function Chain" is ... odd. I believe that > > "their ordering requirements" refers to the ordering of service functio= ns This is actually "their ordering constraints"; I'm not sure how I mistranscribed it. > > within the chain, but "their ordering requirements that must be applied= to > > packets" actually reads that the ordering requirements come from the se= t > > of service functions but is applied to the packets and/or frames. I wo= uld > > probably try to instead say something about "the constraints on the ord= er > > in which service functions are applied to packets and/or frames". > > Additionally, "linear progression" is a bit vague; is the intention jus= t > > to say that it may allow branching and need not be a complete/strict > > ordering (i.e., it could be a partial order)? > > PQ> This oddness can be quickly resolved I think: > > A service Function chain defines an abstract set of service functio= ns > and associated ordering constraints > that must be applied to packets and/or frames selected as a result > of classification. That's an improvement, yes. It might be possible to do better, but it's probably not worth the time. > As for the linear sentence, yes, it is to simply convey that there maybe > a non-linear sequence of functions. Okay. > > In the fourth paragraph of section 2.1, I'm failing to interpret the > > phrase "placement and service function selection taking into account > > network topology information is not viable." Is it adding anything tha= t > > is not said prior to the colon in that sentence? > > PQ> There is some redundancy there that can be cleaned up. Okay. > PQ> We=E2=80=99ll go through the corrections above and clean things as n= eeded. Sure. Thanks for picking up these changes, and helping me resolve my confusion. Sorry it took so long to get back to you. -Ben ---559023410-1969023811-1421344152=:23489-- From nobody Sun Jan 18 09:10:52 2015 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 53EA01ACD70; Sun, 18 Jan 2015 09:10:46 -0800 (PST) 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 ybCNoWlLjpNy; Sun, 18 Jan 2015 09:10:44 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3082E1ACD59; Sun, 18 Jan 2015 09:10:44 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so1198646wes.7; Sun, 18 Jan 2015 09:10:43 -0800 (PST) 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=n85pd8pZMuDGm7RYtA+J6+u08LV1C8Kqd4W3ycuZ6A4=; b=TeoNOavRRl40ByrHZgFp0ZqS29AeGSGTdg/mY9NtzsrMZm2fFxsnQlfWkKnPRblm3e e37/lPUhgugA0OIgQa8bIM72AQR5eVFkc/RbNzNDHbmvJ2xuRcEesZZlIQD0WI0oMKoZ 2FNsWTCLVVHwpASwYFY0XL2RxGiLM3MFnFaxIGkP1mn3QlGjMb654jdxw1nQ9Dyr+Rl6 SzHgiK/32k8XmHSi+bgSCb/tOvaARqHatLxaTn9+Tl9RdzUtRhKXR+vc7HuMPo0B/x7I rK38ekNibEMDvdtUSow3/i7SgL8aRXmJ2NyqZ+mNw43TsxIekKev4mUWTwu3nCD3dmcj xrzw== X-Received: by 10.194.9.4 with SMTP id v4mr51451159wja.115.1421601042958; Sun, 18 Jan 2015 09:10:42 -0800 (PST) Received: from [10.4.162.54] ([80.179.9.115]) by mx.google.com with ESMTPSA id bo5sm8710557wjc.39.2015.01.18.09.10.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Jan 2015 09:10:42 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 18 Jan 2015 19:10:12 +0200 To: draft-ietf-tls-downgrade-scsv.all@tools.ietf.org, secdir , The IESG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03 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, 18 Jan 2015 17:10:46 -0000 Fear not, 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 with the intent of = improving security requirements and considerations in IETF drafts. = Comments not addressed in last call may be included in AD reviews during = the IESG review. Document editors and WG chairs should treat these = comments just like any other last call comments. I believe this document is ready for publication with a few minor = issues. The draft describes a mechanism for mitigating the security issue = introduced by TLS version fallback mechanisms. TLS servers exist that do = not conform to the TLS RFCs with regards to version negotiation. Such = servers fail the negotiation even when there is a version of TLS that is = supported by both them and the client. To interoperate with such = servers, clients often retry the TLS handshake at a lower version. This = is sometimes called the "downgrade dance". The downgrade dance allows a = version downgrade to happen by either an active attacker or because of a = network glitch. This document introduces an indication in the TLS = ClientHello that tells the server that a downgrade dance is in effect, = allowing the server to terminate such a connection. There has been much discussion on the TLS list about the downgrade dance = being inherently insecure, and that publishing this document can be = perceived as "blessing" this practice. The draft takes no position for = or against, but rather assumes that the practice exists, and seeks to = prevent such downgrades that are not necessary for connectivity.=20 The Security Considerations section has some strange text about omitting = the SCSV when "the protocol version given by ClientHello.client_version = still provides an acceptable level of protection". This implies that it = is appropriate to use a protocol version that does not provide and = acceptable level of protection as long as the client sends the SCSV. = This is not the case, and this is the reason that several browsers are = disabling the downgrade to SSLv3. I realize it is difficult to write = text that turns the secure/insecure dichotomy into a trichotomy = (secure/so-so secure/insecure), but if we're going to make including the = SCSV optional we need such text. A scenario that bothers me is a server that returns an = inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with = version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) = server could potentially send the client into an endless loop of regular = and fallback handshake attempts. An attacker could simulate this by = RST-ing all TCP connections with TLS 1.2 in ClientHello. I think the = draft should warn against doing the regular-fallback-regular cycle more = than once. IOW: after receiving the alert, clients MUST NOT perform the = downgrade dance on the following connection. Especially, don't implement = the following downgrade dance: - regular handshake - fallback with SCSV - regular handshake - fallback without SCSV If anyone ends up feeling the need to implement this, then we've failed = miserably. Nits and minor issues: Since the client speaks first, it would make sense to have section 4 = (Client Behavior) before section 3 (Server Behavior). Section 3 = describes how the server responds to this SCSV when the document had = only hinted about when the client should send it. The IANA Considerations are very confusing, saying on the one hand that = no values have been allocated, and on the other hand that IANA has = assigned 0x56,0x00. Unless the authors are requesting that IANA assign = the numbers that they have used in early implementations, it's better to = just write "IANA is requested to assign..." and replace the numbers in = the rest of the documents with TBDs (if you leave actual numbers and = IANA assigns different identifiers, it's likely to be overlooked by the = RFC editor). A few missing articles: "The fallback SCSV defined in this document is not *a* suitable = substitute" "if *the* TLS implementations also include support for (the) predecessor = protocol SSL 3.0" Yoav= From nobody Sun Jan 18 10:18:35 2015 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 082771ACDC6; Sun, 18 Jan 2015 10:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QWenuVoH4VJX; Sun, 18 Jan 2015 10:18:20 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8901ACD73; Sun, 18 Jan 2015 10:18:19 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0IIIH1T001709; Sun, 18 Jan 2015 18:18:17 GMT Received: from 950129200 (91-115-32-217.adsl.highway.telekom.at [91.115.32.217]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0IIIF61001700 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 18 Jan 2015 18:18:16 GMT From: "Adrian Farrel" To: "'Catherine Meadows'" , , , References: In-Reply-To: Date: Sun, 18 Jan 2015 18:18:15 -0000 Message-ID: <00cd01d0334b$21531080$63f93180$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01D0334B.21553360" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAydxp23s1ZdmfGSdynkv0Qges2oQA03Vfw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21262.001 X-TM-AS-Result: No--14.513-10.0-31-10 X-imss-scan-details: No--14.513-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCzdvUwRugvBa8+ihL49RByGbJMFqqIm9yo+b+yOP0oGFiN xVLlNmEJ5Lrq5GvXDdumB9SRxa/C5/DZOKmFLlvI/O70vD0Lt8Bm43Ht6SePHrDpEoP54K7OJ6h vUW0aekQaPfPDdbx4Lyj0q+S3oHr5/SHWB8mv3EGQTsyupo9izSlayzmQ9QV0Z5yuplze9psDU2 Y76gUbDskE8KgAEcqnNzIunSJO7CZzQU+u3L25OfSG/+sPtZVkIcCiCHZJTlfNQVzhfYY5srppS wuYPeB72zNSZa9o4CQktVCwRQiA4xiQc5OixN2zox5cBdU3pAf+paX6bXuNYcXt25YNeIUSM5II ZqvQNz5zmshRjvs1rUmlX2scVfeP7a7m7fE5C+HBtFDYGmaWKrRfRjDbtW6i5DjmdW0+qbGuwVT xTDkELrK2YHb/kidP/PEgL0tqyq50bnu2kHqixLMsPmSZxbpkE7JInT4wddoTjfkO3pb+WD0msI gSyun3H/Z71HJDNaFacyhB9L1arxJ3qw6ad/ljABhihvAhvAJIeNYTP8OmTPk3SjZMcZFkUlBh+ kbitM8/DUc/B6QpkmRGSnUqeCO9OQRl+99vaMkMH4SsGvRsA1qvZZ9/gpIhj2iyfwmt0k9o4tOB Mzo2OOvcLcwP4DFd6uAmoYaXRSDr0sYJGIQqWkHrI6vFzzG7l2F9+KxZd8cL/50zj0KL7BY+750 9sPX7ZLNHiJlyaWEtY3smclWYCYIiDu0n/+6x2MMmxTWvrZv8Xh935PYSDpd9j+WYn72G89EK+x ictMteLYq/LangxG5zP/FSQ4TNuwz3k5k2QyCeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vbyah9aCYUCHVxVyJLA+Rp5XYF+FL+qKPbTNasAJng86tKRxSNDYENnbWGWBiiDqeSoyD/np HYCbm/6zSQZMJ29UD+b1U+lvwxUmBnLsAUB0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-l2vpn-pbb-evpn-09 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: Sun, 18 Jan 2015 18:18:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CE_01D0334B.21553360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Further tweak to tools address to get it delivered! From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 17 January 2015 17:01 To: 'Catherine Meadows'; 'secdir@ietf.org'; 'iesg@ietf.org'; 'draft-ietf-l2vpn-pbb-evpn.all@tools.org' Subject: RE: secdir review of draft-ietf-l2vpn-pbb-evpn-09 Thanks Cathy, [Note tweak to subject line to capture draft name] adrian From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Catherine Meadows Sent: 16 January 2015 22:32 To: secdir@ietf.org; iesg@ietf.org; draft-ietf-l2vpn-pbb-evpn.all@tools.org Cc: Catherine Meadows Subject: secdir review of draft-ietf-12vpn-pbb-evpn-09 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 draft describes a method for integrating Ethernet Provider Backbone Bridge (PBB) with Ethernet VPN (EVPN) to improve the delivery of MAC addresses, in particular with respect to scalability. I don't see any security concerns with this draft, but I do have some comments on the Security Considerations section. It is very short, and all it says that the security considerations in the EVPN draft apply directly to this draft. I assume that it is also the case that this draft introduces no new security considerations. If so, you should say so, and you should also say why. Also, I was wondering if the mechanisms introduced in this draft, by introducing a greater degree of organization in the delivery of MAC addresses, makes it easier to detect duplicated MACs, which were mentioned as a security risk in the Security Considerations of the EVPN draft. If this is the case, it would be a good thing to mention here. I'd consider the draft somewhere between ready with nits and ready with issues. I don't see any real security issues here, just a Security Considerations section that needs to be expanded a little, but this seems to be a little more than what the secdir guidelines would call a nit. Cathy Meadows 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 ------=_NextPart_000_00CE_01D0334B.21553360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Further tweak to tools address to get it = delivered!

 

From: Adrian Farrel = [mailto:adrian@olddog.co.uk]
Sent: 17 January 2015 = 17:01
To: 'Catherine Meadows'; 'secdir@ietf.org'; = 'iesg@ietf.org'; = 'draft-ietf-l2vpn-pbb-evpn.all@tools.org'
Subject: RE: secdir = review of = draft-ietf-l2vpn-pbb-evpn-09

 

Thanks Cathy,

 

[Note tweak to subject line to capture draft = name]

 

adrian

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Catherine = Meadows
Sent: 16 January 2015 22:32
To: = secdir@ietf.org; iesg@ietf.org; = draft-ietf-l2vpn-pbb-evpn.all@tools.org
Cc: Catherine = Meadows
Subject: secdir review of = draft-ietf-12vpn-pbb-evpn-09

 

 

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 draft describes = a method for integrating Ethernet Provider Backbone Bridge (PBB) with = Ethernet VPN (EVPN) to

improve the delivery of MAC addresses, in particular with = respect to scalability.  

 

I don’t see any security concerns with this draft, but I = do have some comments on the Security Considerations = section.

It is very short, = and all it says that the security considerations in the EVPN draft apply = directly to this draft. I assume that

it is also the case that this draft introduces no new security = considerations.  If so, you should say so, and you = should

also say why. =  Also, I was wondering if the mechanisms introduced in this draft, = by introducing a greater degree of = organization

in the delivery of = MAC addresses, makes it easier to detect duplicated MACs, which were = mentioned as a security risk in the

Security Considerations of the EVPN draft.  If this is the = case, it would be a good thing to mention = here.

 

I’d consider the draft somewhere between ready with nits = and ready with issues.  I don’t see any real security = issues

here, just a = Security Considerations section that needs to be expanded a little, but = this seems to be a little more than what = the

secdir guidelines = would call a nit.

 

Cathy Meadows

 

 

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

 

------=_NextPart_000_00CE_01D0334B.21553360-- From nobody Sun Jan 18 12:59:16 2015 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 281C81ACE17; Sun, 18 Jan 2015 12:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ee0Sl0MpobB8; Sun, 18 Jan 2015 12:56:17 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA78D1ACD13; Sun, 18 Jan 2015 12:56:16 -0800 (PST) Received: from mail-la0-f44.google.com ([209.85.215.44]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0LtBoV-1XlPLJ2y8R-012r8N; Sun, 18 Jan 2015 21:56:14 +0100 Received: by mail-la0-f44.google.com with SMTP id hz20so3512392lab.3; Sun, 18 Jan 2015 12:56:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.142.201 with SMTP id ry9mr26535361lbb.4.1421614569148; Sun, 18 Jan 2015 12:56:09 -0800 (PST) Received: by 10.25.25.145 with HTTP; Sun, 18 Jan 2015 12:56:09 -0800 (PST) In-Reply-To: References: Date: Sun, 18 Jan 2015 21:56:09 +0100 Message-ID: From: Bodo Moeller To: Yoav Nir Content-Type: multipart/alternative; boundary=089e011836aa66dbb6050cf36ff8 X-Provags-ID: V03:K0:MykFgAfhUYaOHbJReBn772e9Ilz82b+4nPvv0VsOEGghBuXQVXP xJ+W9Gv+VNz7VyD1HvPtx/GVzIrjDGkMjHj8YICUFoOybj4mzyoajKAiMcqMM4LFa8OmisP ivm5s2EINXjRLAat0by9cR8pl0St4pNDgyOAD9SHVJv67Gf++GHChN8fYo5jExGPjzqR8Bh MMTSuMswNLhG9zmEjmVuA== X-UI-Out-Filterresults: notjunk:1; Archived-At: X-Mailman-Approved-At: Sun, 18 Jan 2015 12:59:16 -0800 Cc: "draft-ietf-tls-downgrade-scsv.all@tools.ietf.org" , The IESG , Adam Langley , secdir Subject: Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03 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, 18 Jan 2015 20:56:19 -0000 --089e011836aa66dbb6050cf36ff8 Content-Type: text/plain; charset=UTF-8 Thanks for your comments, Yoav! > The Security Considerations section has some strange text about omitting > the SCSV when "the protocol version given by ClientHello.client_version > still provides an acceptable level of protection". This implies that it is > appropriate to use a protocol version that does not provide and acceptable > level of protection as long as the client sends the SCSV. This is not the > case, and this is the reason that several browsers are disabling the > downgrade to SSLv3. I realize it is difficult to write text that turns the > secure/insecure dichotomy into a trichotomy (secure/so-so secure/insecure), > but if we're going to make including the SCSV optional we need such text. > Could you make a concrete (if rough) suggestion for what you'd like to see in the document? Note that the text that you cite above was essentially contributed by one of the WG chairs :-) [*] Personally, I don't see a need for additional text because I think that the document already makes it quite clear that the reason why a client might tolerate an otherwise unacceptable level of security when sending the SCSV is as a last resort for connections to legacy servers. Regarding your statement that "this is the reason that several browsers are disabling the downgrade to SSLv3", I don't agree. If TLS_FALLBACK_SCSV was already widely deployed in servers, browser vendors would have had a much less pressuring need to disable the downgrade to SSL 3.0 entirely -- with the SCSV, SSL 3.0 would have been exclusively about hopeless legacy servers anyway, A scenario that bothers me is a server that returns an > inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with > version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) server > could potentially send the client into an endless loop of regular and > fallback handshake attempts. An attacker could simulate this by RST-ing all > TCP connections with TLS 1.2 in ClientHello. I think the draft should warn > against doing the regular-fallback-regular cycle more than once. IOW: after > receiving the alert, clients MUST NOT perform the downgrade dance on the > following connection. The problem is, the alert is not authenticated. (We'd have to complete the handshake to authenticate it.) So a "MUST NOT" can't be right: if a browser users tries to access a web page a second time after the above failure, it's appropriate for the client to perform the entire downgrade dance again if needed. Implementors shouldn't go into infinite reconnect loops, but I don't think there's anything special here about TLS_FALLBACK_SCSV. > Nits and minor issues: > > Since the client speaks first, it would make sense to have section 4 > (Client Behavior) before section 3 (Server Behavior). Section 3 describes > how the server responds to this SCSV when the document had only hinted > about when the client should send it. > My rationale for describing server behavior before client behavior was that I think this makes it easier to read the document, given that server behavior follows simple, concrete, and strict rules. After you've read those in the Server Behavior section, I believe it will be much easier to make sense of the (more complex) section on Client Behavior. If you don't know what server behavior TLS_FALLBACK_SCSV triggers, my fear is that the Client Behavior section will seem very esoteric, abstract, and nebulous. > The IANA Considerations are very confusing, saying on the one hand that no > values have been allocated, and on the other hand that IANA has assigned > 0x56,0x00. Unless the authors are requesting that IANA assign the numbers > that they have used in early implementations, it's better to just write > "IANA is requested to assign..." and replace the numbers in the rest of the > documents with TBDs (if you leave actual numbers and IANA assigns different > identifiers, it's likely to be overlooked by the RFC editor). > Right, the point is specifically to use the numbers that have been used in existing implementations. Isn't the "TO BE REMOVED" note rather clear about that? In any case, the contradictive part obviously isn't meant to go into the final document -- the current form is meant to show the intended final document text while also making it clear that IANA hasn't yet assigned anything. > A few missing articles: > "The fallback SCSV defined in this document is not *a* suitable substitute" > "if *the* TLS implementations also include support for (the) predecessor > protocol SSL 3.0" I don't think either of these is technically necessary, but I'l entirely leave the decision about these articles to my co-author :-) (In the first case, by the way, it's again language contributed by said WG chair. [*]) Bodo [*] No intent to shift any blame: I think the current text is fine, or I wouldn't have used it. However, this lets you know who's in a special position to convince me to change that wording. --089e011836aa66dbb6050cf36ff8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your comments, Yoav!
=

=C2=A0
The Security Considerations section has some strange text about omitting th= e SCSV when "the protocol version given by ClientHello.client_version = still provides an acceptable level of protection". This implies that i= t is appropriate to use a protocol version that does not provide and accept= able level of protection as long as the client sends the SCSV. This is not = the case, and this is the reason that several browsers are disabling the do= wngrade to SSLv3. I realize it is difficult to write text that turns the se= cure/insecure dichotomy into a trichotomy (secure/so-so secure/insecure), b= ut if we're going to make including the SCSV optional we need such text= .

Could you make a concrete (if rough) = suggestion for what you'd like to see in the document?=C2=A0 Note that = the text that you cite above was essentially contributed by one of the WG c= hairs :-) [*] =C2=A0Personally, I don't see a need for additional text = because I think that the document already makes it quite clear that the rea= son why a client might tolerate an otherwise unacceptable level of security= when sending the SCSV is as a last resort for connections to legacy server= s.

Regarding your statement that "this is the= reason that several browsers are disabling the downgrade to SSLv3", I= don't agree.=C2=A0 If TLS_FALLBACK_SCSV was already widely deployed in= servers, browser vendors would have had a much less pressuring need to dis= able the downgrade to SSL 3.0 entirely -- with the SCSV, SSL 3.0 would have= been exclusively about hopeless legacy servers anyway,


A scenario that bothers me is a server that returns an inappropriate_fallba= ck whenever it receives a TLS_FALLBACK_SCSV with version TLS 1.1, but break= s at TLS 1.2. Such an (admittedly broken) server could potentially send the= client into an endless loop of regular and fallback handshake attempts. An= attacker could simulate this by RST-ing all TCP connections with TLS 1.2 i= n ClientHello. I think the draft should warn against doing the regular-fall= back-regular cycle more than once. IOW: after receiving the alert, clients = MUST NOT perform the downgrade dance on the following connection.

The problem is, the alert is not authenticated. =C2= =A0(We'd have to complete the handshake to authenticate it.) =C2=A0So a= "MUST NOT" can't be right: if a browser users tries to acces= s a web page a second time after the above failure, it's appropriate fo= r the client to perform the entire downgrade dance again if needed.=C2=A0 I= mplementors shouldn't go into infinite reconnect loops, but I don't= think there's anything special here about TLS_FALLBACK_SCSV.

=C2=A0
Nits and minor issues:

Since the client speaks first, it would make sense to have section 4 (Clien= t Behavior) before section 3 (Server Behavior). Section 3 describes how the= server responds to this SCSV when the document had only hinted about when = the client should send it.

My rationale= for describing server behavior before client behavior was that I think thi= s makes it easier to read the document, given that server behavior follows = simple, concrete, and strict rules. After you've read those in the Serv= er Behavior section, I believe it will be much easier to make sense of the = (more complex) section on Client Behavior.=C2=A0 If you don't know what= server behavior TLS_FALLBACK_SCSV triggers, my fear is that the Client Beh= avior section will seem very esoteric, abstract, and nebulous.
=C2=A0
The IANA Considerations are very confusing, saying on the one hand that no = values have been allocated, and on the other hand that IANA has assigned 0x= 56,0x00. Unless the authors are requesting that IANA assign the numbers tha= t they have used in early implementations, it's better to just write &q= uot;IANA is requested to assign..." and replace the numbers in the res= t of the documents with TBDs (if you leave actual numbers and IANA assigns = different identifiers, it's likely to be overlooked by the RFC editor).=

Right, the point is specifically to us= e the numbers that have been used in existing implementations.=C2=A0 Isn= 9;t the "TO BE REMOVED" note rather clear about that?=C2=A0 In an= y case, the contradictive part obviously isn't meant to go into the fin= al document -- the current form is meant to show the intended final documen= t text while also making it clear that IANA hasn't yet assigned anythin= g.



A few missing articles:
"The fallback SCSV defined in this document is not *a* suitable substi= tute"
"if *the* TLS implementations also include support for (the) predecess= or protocol SSL 3.0"

I don't think= either of these is technically necessary, but I'l entirely leave the d= ecision about these articles to my co-author :-) =C2=A0(In the first case, = by the way, it's again language contributed by said WG chair. [*])

Bodo


[*] =C2= =A0No intent to shift any blame: I think the current text is fine, or I wou= ldn't have used it.=C2=A0 However, this lets you know who's in a sp= ecial position to convince me to change that wording.

<= /div>
--089e011836aa66dbb6050cf36ff8-- From nobody Sun Jan 18 19:46:37 2015 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 16F521AD0A7; Sun, 18 Jan 2015 19:46:36 -0800 (PST) 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 QK80x_zHLX4L; Sun, 18 Jan 2015 19:46:34 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E784B1AD0A5; Sun, 18 Jan 2015 19:46:33 -0800 (PST) Received: by mail-oi0-f41.google.com with SMTP id i138so25042387oig.0; Sun, 18 Jan 2015 19:46:33 -0800 (PST) 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=YSwuhXnOJj3jISkiMIHLlrrkW5XRJOBKndY5nYYY7Xc=; b=sEjHeBYMn+kHNkNkFwO+Nc/mr8AlMOLs5UFP7LHQZ3FtTrwxuxrCfBwy2cxQU0oAjL a30585pn0CFp1tDlHujEMCK12531fzexIz+wTQHII6DRbPrwRdvteqOjqJb94PlhcnWF SBVa9kSQZVZHW2wGuDQbjZajmjiHy89iqW7pqZ1sHM/pHi5zX0VuPQTDbqBFEM2/+2ek WIjD26/+MFLiYXT6PvZvZIIPIGB0V/IJ3GXdC8Lpvh+2doPJjSA5SwjX1RxJR9inKxcE 7xKX5gtqIeH2tyM2dNaqRmV5CSJTuCm4J3dy3gZJs/dwXesF0de+veXz3Qfe/R6Inm84 vEHw== MIME-Version: 1.0 X-Received: by 10.60.141.103 with SMTP id rn7mr16991212oeb.73.1421639193174; Sun, 18 Jan 2015 19:46:33 -0800 (PST) Received: by 10.202.135.17 with HTTP; Sun, 18 Jan 2015 19:46:33 -0800 (PST) Date: Sun, 18 Jan 2015 22:46:33 -0500 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-httpbis-header-compression.all@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b2e7a4c1ba93c050cf92b10 Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-httpbis-header-compression-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: Mon, 19 Jan 2015 03:46:36 -0000 --047d7b2e7a4c1ba93c050cf92b10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate=E2=80=99s= ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies HPACK, the compression scheme used by HTTP/2. A new compression scheme was needed for HTTP/2 because of attacks against systems where traditional compression schemes were used to compress HTTP headers sent over an encrypted TLS connection. (e.g., the CRIME attack against SPDY.) HPACK is specifically designed to avoid CRIME and similar attacks. I believe that this document is mature and nearly ready for publication. However, I have one concern and would request a change to the document (see below). After reviewing this document and looking at the PETAL paper it references, I am satisfied that -- as the authors claim -- the HPACK scheme [when used to compress HTTP headers] is secure relative to our (the security community) current understanding of attacks against encryption of compressed data. That is, I believe that the authors have adequately addressed -- in the design of HPACK and the associated Security Considerations section -- all known security issues. That being said, since HPACK is a relatively new algorithm, and since encryption of compressed headers is known to be somewhat perilous, it is possible that a clever attacker will develop a new attack in the future (i.e., CRIME++ ) that works against HPACK-compressed header fields. I haven't read the latest version of HTTP/2 carefully enough to know whether HTTP/2 has a mechanism for an implementation to turn off use of HPACK if such an attack is discovered. However, planning for a possible future attack against HPACK would probably be wise. =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 REQUEST FOR CHANGE TO: draft-ietf-httpbis-header-compression The Security Considerations in this document are extremely well-written (particularly Sections 7.1.1 and 7.1.2). Based on experience with the CRIME attack, there are significant security concerns (described in Section 7.1) with encrypting compressed headers. Section 7.1.1 explains how these concerns relate to HPACK and Section 7.1.2 describes steps that an HPACK encoder implementation can take to mitigate these concerns. These sections are very important -- indeed, more important than the security considerations sections for many IETF documents. I would very much like to see a forward reference to Section 7.1.2 (or perhaps just Section 7.1 as whole) at some point earlier in the document when the authors are describing the encoder (probably somewhere in Section 2). That is, there are important mitigation techniques that an implementer should have in mind when creating an HPACK encoder. I believe that referencing these techniques when the encoding process is described would be a good idea. =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 --047d7b2e7a4c1ba93c050cf92b10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have review= ed this document as part of the security directorate=E2=80=99s ongoing effo= rt to review all IETF documents being processed by the IESG.=C2=A0 These co= mments were written with the intent of improving security requirements and = considerations in IETF drafts.=C2=A0 Comments not addressed in last call ma= y be included in AD reviews during the IESG review.=C2=A0 Document editors = and WG chairs should treat these comments just like any other last call com= ments.

This document sp= ecifies HPACK, the compression scheme used by HTTP/2. A new compression sch= eme was needed for HTTP/2 because of attacks against systems where traditio= nal compression schemes were used to compress HTTP headers sent over an enc= rypted TLS connection. (e.g., the CRIME attack against SPDY.) HPACK is spec= ifically designed to avoid CRIME and similar attacks.

I believe th= at this document is mature and nearly ready for publication. However, I hav= e one concern and would request a change to the document (see below).
=

After reviewing this document and looking at the PETAL = paper it references, I am satisfied that -- as the authors claim -- the HPA= CK scheme [when used to compress HTTP headers] is secure relative to our (t= he security community) current understanding of attacks against encryption = of compressed data. That is, I believe that the authors have adequately add= ressed -- in the design of HPACK and the associated Security Considerations= section -- all known security issues.=C2=A0

That = being said, since HPACK is a relatively new algorithm, and since encryption= of compressed headers is known to be somewhat perilous, it is possible tha= t a clever attacker will develop a new attack in the future (i.e., CRIME++ = ) that works against HPACK-compressed header fields. I haven't read the= latest version of HTTP/2 carefully enough to know whether HTTP/2 has a mec= hanism for an implementation to turn off use of HPACK if such an attack is = discovered. However, planning for a possible future attack against HPACK wo= uld probably be wise.

=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
REQUEST FOR C= HANGE TO:=C2=A0draft-ietf-httpbis-header-compression

The Security Considerations in this document are extremely well-written = (particularly Sections 7.1.1 and 7.1.2). Based on experience with the CRIME= attack, there are significant security concerns (described in Section 7.1)= with encrypting compressed headers. Section 7.1.1 explains how these conce= rns relate to HPACK and Section 7.1.2 describes steps that an HPACK encoder= implementation can take to mitigate these concerns. These sections are ver= y important -- indeed, more important than the security considerations sect= ions for many IETF documents.

I would very much li= ke to see a forward reference to Section 7.1.2 (or perhaps just Section 7.1= as whole) at some point earlier in the document =C2=A0when the authors are= describing the encoder (probably somewhere in Section 2). That is, there a= re important mitigation techniques that an implementer should have in mind = when creating an HPACK encoder. I believe that referencing these techniques= when the encoding process is described would be a good idea.=C2=A0
=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
--047d7b2e7a4c1ba93c050cf92b10-- From nobody Sun Jan 18 23:12:28 2015 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 345F91AD182; Sun, 18 Jan 2015 23:11:55 -0800 (PST) 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 A9W-okK9RAlH; Sun, 18 Jan 2015 23:11:44 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D921AD16B; Sun, 18 Jan 2015 23:11:43 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id l61so4427151wev.13; Sun, 18 Jan 2015 23:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ov/Fhb/5Ahi/mUnzIyr0iDtIMDV8BgezQJnIuujXwho=; b=sGTYlWkA5PBTP4M1cEBfIhYiPqq1EIgrTYGD59lUtVCXdQl6faGQq1EME5/nYOw4Sz kY9pRUL9PDIAWcHUo/GUO6x5BcLVrbDVHpKjd21XLRHB94OJKKs7/I1RO9WHuIBx+Xkq f+9NYTmMl6tBJ0ZdGJTHyHtQnH7oQ3rLKNO/+v/WAcrtH0WcOtyVh2n3ZOTy9GLyaWIR mpx/G8/EkRl4di25Qv9AYVC7g1/AulO2MyqAajVZdT+4Jr+5WVvjKvqTCs0fm/YFQQB/ pJHNzfeCAJUZrpfZldBm9UTV6znDHFDVkcrvLPVHWraSQPyOZpPGffLm7i+nRubOA/qg mmOA== X-Received: by 10.180.82.137 with SMTP id i9mr33023368wiy.38.1421651502366; Sun, 18 Jan 2015 23:11:42 -0800 (PST) Received: from [10.4.12.197] ([80.179.9.115]) by mx.google.com with ESMTPSA id b1sm13050806wiz.6.2015.01.18.23.11.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Jan 2015 23:11:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B31298F4-C553-4994-AB9B-B07B871DD9FF" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Mon, 19 Jan 2015 09:11:28 +0200 Message-Id: <63164CA2-62C1-4E6C-A3F1-F67F92C26F0F@gmail.com> References: To: Bodo Moeller X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "draft-ietf-tls-downgrade-scsv.all@tools.ietf.org" , The IESG , Adam Langley , secdir Subject: Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03 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, 19 Jan 2015 07:11:55 -0000 --Apple-Mail=_B31298F4-C553-4994-AB9B-B07B871DD9FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 18, 2015, at 10:56 PM, Bodo Moeller wrote: >=20 > Thanks for your comments, Yoav! >=20 > =20 > The Security Considerations section has some strange text about = omitting the SCSV when "the protocol version given by = ClientHello.client_version still provides an acceptable level of = protection". This implies that it is appropriate to use a protocol = version that does not provide and acceptable level of protection as long = as the client sends the SCSV. This is not the case, and this is the = reason that several browsers are disabling the downgrade to SSLv3. I = realize it is difficult to write text that turns the secure/insecure = dichotomy into a trichotomy (secure/so-so secure/insecure), but if we're = going to make including the SCSV optional we need such text. >=20 > Could you make a concrete (if rough) suggestion for what you'd like to = see in the document? Note that the text that you cite above was = essentially contributed by one of the WG chairs :-) [*] Personally, I = don't see a need for additional text because I think that the document = already makes it quite clear that the reason why a client might tolerate = an otherwise unacceptable level of security when sending the SCSV is as = a last resort for connections to legacy servers. >=20 > Regarding your statement that "this is the reason that several = browsers are disabling the downgrade to SSLv3", I don't agree. If = TLS_FALLBACK_SCSV was already widely deployed in servers, browser = vendors would have had a much less pressuring need to disable the = downgrade to SSL 3.0 entirely -- with the SCSV, SSL 3.0 would have been = exclusively about hopeless legacy servers anyway, I could ask what is so bad then with downgrade attacks, since it=E2=80=99s= apparently SSLv3 is good enough for the client and good enough for the = server. What do we care then if we get there through a software bug, an = active attack or just misconfiguration? We still get an acceptable level = of security, or we wouldn=E2=80=99t support it. I=E2=80=99m not really making this argument, because I realize that the = realities of deploying protocols and products is such that you sometimes = want to assume some level of risk when connecting to a server. The text = in the security considerations is describing a less secure practice than = in the rest of the document. It=E2=80=99s saying that it=E2=80=99s OK to = allow the downgrade to some TLS versions that are still considered = secure enough. So I would start with the justification. Something like: =E2=80=9CAdding anything to a TLS handshake runs the risk of causing = interoperability problems with non-compliant implementations. Such = behavior is even more likely in servers that did not implement version = negotiation properly. In order to avoid unnecessary connectivity = problems, clients MAY omit the TLS_FALLBACK_SCSV when downgrading to a = version of TLS that is still considered secure.=E2=80=9D BTW: since the working group has an active document deprecating SSLv3 = (https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00 = ), you = might consider removing the "permission" to downgrade to SSLv3. > A scenario that bothers me is a server that returns an = inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with = version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) = server could potentially send the client into an endless loop of regular = and fallback handshake attempts. An attacker could simulate this by = RST-ing all TCP connections with TLS 1.2 in ClientHello. I think the = draft should warn against doing the regular-fallback-regular cycle more = than once. IOW: after receiving the alert, clients MUST NOT perform the = downgrade dance on the following connection. >=20 > The problem is, the alert is not authenticated. (We'd have to = complete the handshake to authenticate it.) So a "MUST NOT" can't be = right: if a browser users tries to access a web page a second time after = the above failure, it's appropriate for the client to perform the entire = downgrade dance again if needed. Implementors shouldn't go into = infinite reconnect loops, but I don't think there's anything special = here about TLS_FALLBACK_SCSV. I=E2=80=99m fine with trying the whole thing again if the user refreshes = the browser. What I think you should warn about is an automatic endless = loop. When the TLS 1.2 connection gets a RST, the browser automatically = retries at a lower version, no user interaction required. If that leads = to an inappropriate_fallback alert, the client =E2=80=9Cshould then = retry with the highest version it supports=E2=80=9D. This makes it seem = that a particularly broken server could have the client retrying = handshakes indefinitely, so to that sentence, I would add =E2=80=9Cand = not attempt downgrades if that handshake should fail." >=20 > =20 > Nits and minor issues: >=20 > Since the client speaks first, it would make sense to have section 4 = (Client Behavior) before section 3 (Server Behavior). Section 3 = describes how the server responds to this SCSV when the document had = only hinted about when the client should send it. >=20 > My rationale for describing server behavior before client behavior was = that I think this makes it easier to read the document, given that = server behavior follows simple, concrete, and strict rules. After you've = read those in the Server Behavior section, I believe it will be much = easier to make sense of the (more complex) section on Client Behavior. = If you don't know what server behavior TLS_FALLBACK_SCSV triggers, my = fear is that the Client Behavior section will seem very esoteric, = abstract, and nebulous. OK.=20 > The IANA Considerations are very confusing, saying on the one hand = that no values have been allocated, and on the other hand that IANA has = assigned 0x56,0x00. Unless the authors are requesting that IANA assign = the numbers that they have used in early implementations, it's better to = just write "IANA is requested to assign..." and replace the numbers in = the rest of the documents with TBDs (if you leave actual numbers and = IANA assigns different identifiers, it's likely to be overlooked by the = RFC editor). >=20 > Right, the point is specifically to use the numbers that have been = used in existing implementations. Isn't the "TO BE REMOVED" note rather = clear about that? In any case, the contradictive part obviously isn't = meant to go into the final document -- the current form is meant to show = the intended final document text while also making it clear that IANA = hasn't yet assigned anything. Sure. IANA will weigh in on your draft, as they do on all documents, so = that=E2=80=99s between you, them and the designated expert. >=20 > A few missing articles: > "The fallback SCSV defined in this document is not *a* suitable = substitute" > "if *the* TLS implementations also include support for (the) = predecessor protocol SSL 3.0" >=20 > I don't think either of these is technically necessary, but I'l = entirely leave the decision about these articles to my co-author :-) = (In the first case, by the way, it's again language contributed by said = WG chair. [*]) As a non-native English speaker, I=E2=80=99ll leave the grammar = corrections to you and the RFC editor (although some ADs tend to engage = in that as well) Yoav --Apple-Mail=_B31298F4-C553-4994-AB9B-B07B871DD9FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 18, 2015, at 10:56 PM, Bodo Moeller <bmoeller@acm.org> = wrote:

Thanks for your comments, Yoav!

 
The Security Considerations section has some strange text about omitting = the SCSV when "the protocol version given by ClientHello.client_version = still provides an acceptable level of protection". This implies that it = is appropriate to use a protocol version that does not provide and = acceptable level of protection as long as the client sends the SCSV. = This is not the case, and this is the reason that several browsers are = disabling the downgrade to SSLv3. I realize it is difficult to write = text that turns the secure/insecure dichotomy into a trichotomy = (secure/so-so secure/insecure), but if we're going to make including the = SCSV optional we need such text.

Could you make a = concrete (if rough) suggestion for what you'd like to see in the = document?  Note that the text that you cite above was essentially = contributed by one of the WG chairs :-) [*]  Personally, I don't = see a need for additional text because I think that the document already = makes it quite clear that the reason why a client might tolerate an = otherwise unacceptable level of security when sending the SCSV is as a = last resort for connections to legacy servers.

Regarding your statement that "this is = the reason that several browsers are disabling the downgrade to SSLv3", = I don't agree.  If TLS_FALLBACK_SCSV was already widely deployed in = servers, browser vendors would have had a much less pressuring need to = disable the downgrade to SSL 3.0 entirely -- with the SCSV, SSL 3.0 = would have been exclusively about hopeless legacy servers = anyway,

I could ask what is so bad then with downgrade attacks, = since it=E2=80=99s apparently SSLv3 is good enough for the client and = good enough for the server. What do we care then if we get there through = a software bug, an active attack or just misconfiguration? We still get = an acceptable level of security, or we wouldn=E2=80=99t support = it.

I=E2=80=99m not really making = this argument, because I realize that the realities of deploying = protocols and products is such that you sometimes want to assume some = level of risk when connecting to a server. The text in the security = considerations is describing a less secure practice than in the rest of = the document. It=E2=80=99s saying that it=E2=80=99s OK to allow the = downgrade to some TLS versions that are still considered secure enough. = So I would start with the justification. Something like:

=E2=80=9CAdding anything to a TLS handshake runs = the risk of causing interoperability problems with non-compliant = implementations. Such behavior is even more likely in servers that did = not implement version negotiation properly. In order to avoid = unnecessary connectivity problems, clients MAY omit the = TLS_FALLBACK_SCSV when downgrading to a version of TLS that is still = considered secure.=E2=80=9D



A scenario that bothers me is a server that returns an = inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with = version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) = server could potentially send the client into an endless loop of regular = and fallback handshake attempts. An attacker could simulate this by = RST-ing all TCP connections with TLS 1.2 in ClientHello. I think the = draft should warn against doing the regular-fallback-regular cycle more = than once. IOW: after receiving the alert, clients MUST NOT perform the = downgrade dance on the following connection.

The problem is, the = alert is not authenticated.  (We'd have to complete the handshake = to authenticate it.)  So a "MUST NOT" can't be right: if a browser = users tries to access a web page a second time after the above failure, = it's appropriate for the client to perform the entire downgrade dance = again if needed.  Implementors shouldn't go into infinite reconnect = loops, but I don't think there's anything special here about = TLS_FALLBACK_SCSV.

I=E2=80=99m fine with trying the whole thing again = if the user refreshes the browser. What I think you should warn about is = an automatic endless loop. When the TLS 1.2 connection gets a RST, the = browser automatically retries at a lower version, no user interaction = required. If that leads to an inappropriate_fallback alert, the client = =E2=80=9Cshould then retry with the highest version it supports=E2=80=9D. = This makes it seem that a particularly broken server could have the = client retrying handshakes indefinitely, so to that sentence, I would = add =E2=80=9Cand not attempt downgrades if that handshake should = fail."


 
Nits and minor issues:

Since the client speaks first, it would make sense to have section 4 = (Client Behavior) before section 3 (Server Behavior). Section 3 = describes how the server responds to this SCSV when the document had = only hinted about when the client should send it.

My rationale for describing server behavior before client = behavior was that I think this makes it easier to read the document, = given that server behavior follows simple, concrete, and strict rules. = After you've read those in the Server Behavior section, I believe it = will be much easier to make sense of the (more complex) section on = Client Behavior.  If you don't know what server behavior = TLS_FALLBACK_SCSV triggers, my fear is that the Client Behavior section = will seem very esoteric, abstract, and = nebulous.

OK. 

The IANA Considerations are very confusing, saying on the one hand that = no values have been allocated, and on the other hand that IANA has = assigned 0x56,0x00. Unless the authors are requesting that IANA assign = the numbers that they have used in early implementations, it's better to = just write "IANA is requested to assign..." and replace the numbers in = the rest of the documents with TBDs (if you leave actual numbers and = IANA assigns different identifiers, it's likely to be overlooked by the = RFC editor).

Right, the point is specifically to use = the numbers that have been used in existing implementations.  Isn't = the "TO BE REMOVED" note rather clear about that?  In any case, the = contradictive part obviously isn't meant to go into the final document = -- the current form is meant to show the intended final document text = while also making it clear that IANA hasn't yet assigned = anything.

Sure. IANA will weigh in on your draft, as they do on = all documents, so that=E2=80=99s between you, them and the designated = expert.



= --Apple-Mail=_B31298F4-C553-4994-AB9B-B07B871DD9FF-- From nobody Mon Jan 19 10:47:59 2015 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 41D831B2BC7 for ; Mon, 19 Jan 2015 10:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Aw3iS-CfcV8z for ; Mon, 19 Jan 2015 10:47:53 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF611B2BFC for ; Mon, 19 Jan 2015 10:47:53 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id r5so21211728qcx.11 for ; Mon, 19 Jan 2015 10:47:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=78a7n/WWlnobWbC6nup8BHItB+lXKeMzeIQwKNaXX2Q=; b=add8soAJFZfHUER6/WMUUVp1lXbjzTQvbfYG0B61glNFnJFo5nnujZP7gJABES0jod yNLr6O3o3FtxzD4B/UMmE3pXQm7ywjL9ZQBigCy94tGi9g/DhJaK9Klj8b+MSVuiEFAR PmMWR8XMaC776MTgHsFMHdMsKH/UF+KJSCiVQa7+8vtIeVS1V82QiXBacZzcTkwxhPu5 H5+o9zbOTLHcC0GH+eCHd/FPwYZvqOOvYixBPQqUm0OC9T0nXqw9RSKhHqOH9+S23vq2 FlFidrzJybGYqS0B4ADgst350fi9l8Cs2WIe2X8NFAJuW+0e1/RyQXwPHvu9d+Dl/ScC oO9w== X-Gm-Message-State: ALoCoQlmiSGjv+bLcPgbNFGmeiVMyqNFIGHXOC8/CdNa4ZtAlvnR8XmzV5WHc/KR6gYvFMuXFeqj MIME-Version: 1.0 X-Received: by 10.140.92.138 with SMTP id b10mr47368356qge.59.1421693271919; Mon, 19 Jan 2015 10:47:51 -0800 (PST) Received: by 10.96.238.73 with HTTP; Mon, 19 Jan 2015 10:47:51 -0800 (PST) X-Originating-IP: [50.206.82.141] In-Reply-To: References: <63164CA2-62C1-4E6C-A3F1-F67F92C26F0F@gmail.com> Date: Mon, 19 Jan 2015 10:47:51 -0800 Message-ID: From: Joseph Salowey To: Bodo Moeller Content-Type: multipart/alternative; boundary=001a113a5d5e7441d0050d05c270 Archived-At: Cc: "draft-ietf-tls-downgrade-scsv.all@tools.ietf.org" , Adam Langley , The IESG , secdir Subject: Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03 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, 19 Jan 2015 18:47:58 -0000 --001a113a5d5e7441d0050d05c270 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 19, 2015 at 3:15 AM, Bodo Moeller wrote: > Regarding your statement that "this is the reason that several browsers >> are disabling the downgrade to SSLv3", I don't agree. If TLS_FALLBACK_S= CSV >> was already widely deployed in servers, browser vendors would have had a >> much less pressuring need to disable the downgrade to SSL 3.0 entirely -= - >> with the SCSV, SSL 3.0 would have been exclusively about hopeless legacy >> servers anyway, >> >> >> I could ask what is so bad then with downgrade attacks, since it=E2=80= =99s >> apparently SSLv3 is good enough for the client and good enough for the >> server. What do we care then if we get there through a software bug, an >> active attack or just misconfiguration? We still get an acceptable level= of >> security, or we wouldn=E2=80=99t support it. >> > > It's certainly not good enough in general, but if it's the best you can > get with a particular server, you might prefer it over not being able to > use any kind of encryption (however weak) at all, and in particular you > might prefer it over a connection failure. If you browse the web, you > don't necessarily always care about HTTPS for all servers -- and if you > don't really trust a particular HTTPS server and don't exchange any secre= ts > (such as passwords) with it, even ROT13 might be "acceptable" for > connections to that specific server because the connection could just as > well be using plaintext HTTP. Assuming that all servers that you actuall= y > care about have been updated to support a better protocol version, you'd > want the handshake to make sure that connections to any of these servers > actually use that protocol. > > So my point is that there isn't necessarily a single minimum security > level to be required for *all* connections. For many applications, there > may be one (and you'd probably disable plaintext connections entirely for > these), but in general, draft-ietf-tls-downgrade-scsv-03 is about helping > you achieve the best security level that is possible with a particular > server. > > I don't mean to imply that SSL 3.0 shouldn't be disallowed entirely, but > consider TLS 1.0 instead. So maybe we don't know a fatal weakness in TLS > 1.0 at this time, and thus TLS 1.0 is probably still "acceptable" for > connections to servers that don't support anything better. However, if t= he > server speaks TLS 1.2 (or, in the future, TLS 1.3), we'd want to insist o= n > using the newer protocol version -- so TLS 1.0 is "unacceptable" for thes= e > connections. We don't necessarily yet know all the concrete reasons to > avoid the earlier protocol version. Whether you should disallow TLS 1.0 > entirely because it's now an obsolete protocol is simply not a question > that draft-ietf-tls-downgrade-scsv-03 is about. > > So you can have a long and complicated discussion about which protocol > version is acceptable or unacceptable when. The question is, what of that > belongs into draft-ietf-tls-downgrade-scsv-03 and what would rather be > distracting? > > Currently the document mentions that downgraded connections can be "a > useful last resort for connections to actual legacy servers" and that > "unnecessary protocol downgrades are undesirable". I'm hoping that this > will be enough, but maybe it's possible to write something that will help > make things clearer without creating additional confusion. What would yo= u > think of an additional sentence that simply points out that implementatio= ns > will typically want to disallow certain protocol variants entirely (even > with TLS_FALLBACK_SCSV), but that any details of this are out of scope of > the document? > > > [Joe] Just to clarify, my intention with this text was to warn against eliminating the SCSV and therefore the downgrade protection it provides. My intention was not to say that it is OK to use a version that you normally would not allow if you include the SCSV. I'd be OK with additional text that says you want to disallow unacceptable protocol variants entirely even with TLS_FALLBACK_SCSV. I'm open to other suggestions for improving the text. > > >> I=E2=80=99m not really making this argument, because I realize that the = realities >> of deploying protocols and products is such that you sometimes want to >> assume some level of risk when connecting to a server. The text in the >> security considerations is describing a less secure practice than in the >> rest of the document. It=E2=80=99s saying that it=E2=80=99s OK to allow = the downgrade to >> some TLS versions that are still considered secure enough. So I would st= art >> with the justification. Something like: >> >> =E2=80=9CAdding anything to a TLS handshake runs the risk of causing >> interoperability problems with non-compliant implementations. Such behav= ior >> is even more likely in servers that did not implement version negotiatio= n >> properly. In order to avoid unnecessary connectivity problems, clients M= AY >> omit the TLS_FALLBACK_SCSV when downgrading to a version of TLS that is >> still considered secure.=E2=80=9D >> > > This doesn't really cover all reasons why you might want to omit > TLS_FALLBACK_SCSV from some downgraded handshakes. I'm not too worried > about TLS_FALLBACK_SCSV being mishandled by non-compliant implementations= . > I'm more worried about a TLS 1.2 + TLS 1.3 server rejecting a TLS 1.2 > handshake with TLS_FALLBACK_SCSV *because* it complies with the > specification, after an earlier TLS 1.3 handshake attempt has failed > because the server or the client (or both) have bugs in their TLS 1.3 cod= e > (or because they implement incompatible I-Ds for TLS 1.3). > > > >> BTW: since the working group has an active document deprecating SSLv3 ( >> https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00), you >> might consider removing the "permission" to downgrade to SSLv3. >> > > Hm, draft-ietf-tls-downgrade-scsv-03 doesn't intend to "allow" any > particular downgrade. What it's telling clients, rather, is "If you must > downgrade, then at least send TLS_FALLBACK_SCSV". (Of course, any > instructions concerning SSL 3.0 are moot as soon as no one downgrades to > SSL 3.0, but we need to avoid any risk of ending up with client > implementations that include TLS_FALLBACK_SCSV in any *TLS* fallbacks but > ultimately fall back to SSL 3.0 without the SCSV -- so we can't just > pretend that SSL 3.0 doesn't exist.) > > > A scenario that bothers me is a server that returns an >>> inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with >>> version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) ser= ver >>> could potentially send the client into an endless loop of regular and >>> fallback handshake attempts. An attacker could simulate this by RST-ing= all >>> TCP connections with TLS 1.2 in ClientHello. I think the draft should w= arn >>> against doing the regular-fallback-regular cycle more than once. IOW: a= fter >>> receiving the alert, clients MUST NOT perform the downgrade dance on th= e >>> following connection. >> >> >> The problem is, the alert is not authenticated. (We'd have to complete >> the handshake to authenticate it.) So a "MUST NOT" can't be right: if a >> browser users tries to access a web page a second time after the above >> failure, it's appropriate for the client to perform the entire downgrade >> dance again if needed. Implementors shouldn't go into infinite reconnec= t >> loops, but I don't think there's anything special here about >> TLS_FALLBACK_SCSV. >> >> >> I=E2=80=99m fine with trying the whole thing again if the user refreshes= the >> browser. What I think you should warn about is an automatic endless loop= . >> When the TLS 1.2 connection gets a RST, the browser automatically retrie= s >> at a lower version, no user interaction required. If that leads to an >> inappropriate_fallback alert, the client =E2=80=9Cshould then retry with= the >> highest version it supports=E2=80=9D. This makes it seem that a particul= arly broken >> server could have the client retrying handshakes indefinitely, so to tha= t >> sentence, I would add =E2=80=9Cand not attempt downgrades if that handsh= ake should >> fail." >> > > The full sentence that you're referring to is "Thus, if a client intends > to use retries to work around network glitches, it should then retry with > the highest version it supports." This isn't meant to instruct clients t= o > retry, it just tells them how to do any retries. Apart from that aspect, > it's not specific to TLS_FALLBACK_SCSV, and I don't want to add unwarrant= ed > regulation of implementation details. If a client would normally retry > multiple times to work around network glitches, that's still just as > acceptable (or unacceptable) with TLS_FALLBACK_SCSV, even if it means goi= ng > through the downgrade dance multiple times automatically. If a client > would normally retry in an infinite loop (hopefully, with exponential > backoff), that's just as acceptable (or unacceptable) with > TLS_FALLBACK_SCSV. We may have opinions on any of these design choices, > but those don't really belong into draft-ietf-tls-downgrade-scsv-03. > > Maybe that sentence can be made clearer, though. How about rewriting tha= t > paragraph as follows (the first sentence is unchanged)? > > "Fallback retries could be caused by events such as network glitches, and > a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may > receive an inappropriate_fallback alert in response, indicating that the > server supports a higher protocol version. Thus, if a client intends to u= se > retries to work around network glitches, the next retry after an > inappropriate_fallback alert should use the highest version that the clie= nt > supports." > > > > A few missing articles: >>> "The fallback SCSV defined in this document is not *a* suitable >>> substitute" >>> "if *the* TLS implementations also include support for (the) predecesso= r >>> protocol SSL 3.0" >> >> >> I don't think either of these is technically necessary, but I'l entirely >> leave the decision about these articles to my co-author :-) (In the fir= st >> case, by the way, it's again language contributed by said WG chair. [*]) >> >> >> As a non-native English speaker, I=E2=80=99ll leave the grammar correcti= ons to >> you and the RFC editor (although some ADs tend to engage in that as well= ) >> > > Which is why I'll need Adam for these decisions :-) > > Bodo > > > --001a113a5d5e7441d0050d05c270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 19, 2015 at 3:15 AM, Bodo Moeller <bmoeller@acm.org>= wrote:
<= div class=3D"gmail_extra">
Regarding your st= atement that "this is the reason that several browsers are disabling t= he downgrade to SSLv3", I don't agree.=C2=A0 If TLS_FALLBACK_SCSV = was already widely deployed in servers, browser vendors would have had a mu= ch less pressuring need to disable the downgrade to SSL 3.0 entirely -- wit= h the SCSV, SSL 3.0 would have been exclusively about hopeless legacy serve= rs anyway,

= I could ask what is so bad then with downgrade attacks, since it=E2=80=99s = apparently SSLv3 is good enough for the client and good enough for the serv= er. What do we care then if we get there through a software bug, an active = attack or just misconfiguration? We still get an acceptable level of securi= ty, or we wouldn=E2=80=99t support it.

It's certainly not good enough in general, but if it'= ;s the best you can get with a particular server, you might prefer it over = not being able to use any kind of encryption (however weak) at all, and in = particular you might prefer it over a connection failure.=C2=A0 If you brow= se the web, you don't necessarily always care about HTTPS for all serve= rs -- and if you don't really trust a particular HTTPS server and don&#= 39;t exchange any secrets (such as passwords) with it, even ROT13 might be = "acceptable" for connections to that specific server because the = connection could just as well be using plaintext HTTP.=C2=A0 Assuming that = all servers that you actually care about have been updated to support a bet= ter protocol version, you'd want the handshake to make sure that connec= tions to any of these servers actually use that protocol.

So my point is that there isn't necessarily a single minimum se= curity level to be required for *all* connections.=C2=A0 For many applicati= ons, there may be one (and you'd probably disable plaintext connections= entirely for these), but in general, draft-ietf-tls-downgrade-scsv-03 is a= bout helping you achieve the best security level that is possible with a pa= rticular server.

I don't mean to imply that SS= L 3.0 shouldn't be disallowed entirely, but consider TLS 1.0 instead.= =C2=A0 So maybe we don't know a fatal weakness in TLS 1.0 at this time,= and thus TLS 1.0 is probably still "acceptable" for connections = to servers that don't support anything better.=C2=A0 However, if the se= rver speaks TLS 1.2 (or, in the future, TLS 1.3), we'd want to insist o= n using the newer protocol version -- so TLS 1.0 is "unacceptable"= ; for these connections.=C2=A0 We don't necessarily yet know all the co= ncrete reasons to avoid the earlier protocol version.=C2=A0 Whether you sho= uld disallow TLS 1.0 entirely because it's now an obsolete protocol is = simply not a question that draft-ietf-tls-downgrade-scsv-03 is about.
=

So you can have a long and complicated discussion about= which protocol version is acceptable or unacceptable when. The question is= , what of that belongs into draft-ietf-tls-downgrade-scsv-03 and what would= rather be distracting?

Currently the document men= tions that downgraded connections can be "a useful last resort for con= nections to actual legacy servers" and that "unnecessary protocol= downgrades are undesirable".=C2=A0 I'm hoping that this will be e= nough, but maybe it's possible to write something that will help make t= hings clearer without creating additional confusion.=C2=A0 What would you t= hink of an additional sentence that simply points out that implementations = will typically want to disallow certain protocol variants entirely (even wi= th TLS_FALLBACK_SCSV), but that any details of this are out of scope of the= document?




[Joe] Just to clarify, my= intention with this text was to warn against eliminating the SCSV and ther= efore the downgrade protection it provides. My intention was not to say tha= t it is OK to use a version that you normally would not allow if you includ= e the SCSV. I'd be OK with additional text that says you want to disall= ow unacceptable protocol variants entirely even with TLS_FALLBACK_SCSV. =C2= =A0 I'm open to other suggestions for improving the text.=C2=A0
=C2=A0
=C2=A0
I=E2=80=99m not= really making this argument, because I realize that the realities of deplo= ying protocols and products is such that you sometimes want to assume some = level of risk when connecting to a server. The text in the security conside= rations is describing a less secure practice than in the rest of the docume= nt. It=E2=80=99s saying that it=E2=80=99s OK to allow the downgrade to some= TLS versions that are still considered secure enough. So I would start wit= h the justification. Something like:

=E2=80=9CAddi= ng anything to a TLS handshake runs the risk of causing interoperability pr= oblems with non-compliant implementations. Such behavior is even more likel= y in servers that did not implement version negotiation properly. In order = to avoid unnecessary connectivity problems, clients MAY omit the TLS_FALLBA= CK_SCSV when downgrading to a version of TLS that is still considered secur= e.=E2=80=9D

This doesn&#= 39;t really cover all reasons why you might want to omit TLS_FALLBACK_SCSV = from some downgraded handshakes.=C2=A0 I'm not too worried about TLS_FA= LLBACK_SCSV being mishandled by non-compliant implementations.=C2=A0 I'= m more worried about a TLS 1.2 + TLS 1.3 server rejecting a TLS 1.2 handsha= ke with TLS_FALLBACK_SCSV *because* it complies with the specification, aft= er an earlier TLS 1.3 handshake attempt has failed because the server or th= e client (or both) have bugs in their TLS 1.3 code (or because they impleme= nt incompatible I-Ds for TLS 1.3).

=C2=A0



A scenario that bothers me is a server th= at returns an inappropriate_fallback whenever it receives a TLS_FALLBACK_SC= SV with version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken)= server could potentially send the client into an endless loop of regular a= nd fallback handshake attempts. An attacker could simulate this by RST-ing = all TCP connections with TLS 1.2 in ClientHello. I think the draft should w= arn against doing the regular-fallback-regular cycle more than once. IOW: a= fter receiving the alert, clients MUST NOT perform the downgrade dance on t= he following connection.

The problem is, th= e alert is not authenticated. =C2=A0(We'd have to complete the handshak= e to authenticate it.) =C2=A0So a "MUST NOT" can't be right: = if a browser users tries to access a web page a second time after the above= failure, it's appropriate for the client to perform the entire downgra= de dance again if needed.=C2=A0 Implementors shouldn't go into infinite= reconnect loops, but I don't think there's anything special here a= bout TLS_FALLBACK_SCSV.

=
I=E2=80=99m fine with trying the whole thing again if the= user refreshes the browser. What I think you should warn about is an autom= atic endless loop. When the TLS 1.2 connection gets a RST, the browser auto= matically retries at a lower version, no user interaction required. If that= leads to an inappropriate_fallback alert, the client =E2=80=9Cshould then = retry with the highest version it supports=E2=80=9D. This makes it seem tha= t a particularly broken server could have the client retrying handshakes in= definitely, so to that sentence, I would add =E2=80=9Cand not attempt downg= rades if that handshake should fail."

The full sentence that you're referring to is = "Thus, if a client intends to use retries to work around network glitc= hes, it should then retry with the highest version it supports." =C2= =A0This isn't meant to instruct clients to retry, it just tells them ho= w to do any retries.=C2=A0 Apart from that aspect, it's not specific to= TLS_FALLBACK_SCSV, and I don't want to add unwarranted regulation of i= mplementation details.=C2=A0 If a client would normally retry multiple time= s to work around network glitches, that's still just as acceptable (or = unacceptable) with TLS_FALLBACK_SCSV, even if it means going through the do= wngrade dance multiple times automatically.=C2=A0 If a client would normall= y retry in an infinite loop (hopefully, with exponential backoff), that'= ;s just as acceptable (or unacceptable) with TLS_FALLBACK_SCSV.=C2=A0 We ma= y have opinions on any of these design choices, but those don't really = belong into=C2=A0draft-ietf-tls-downgrade-scsv-03.

Maybe that sentence can be made clearer, though.=C2=A0 How about rewriting= that paragraph as follows (the first sentence is unchanged)?


A few missing articles:
"The fallback SCSV defined in this document is not *a* suitable substi= tute"
"if *the* TLS implementations also include support for (the) predecess= or protocol SSL 3.0"

I don't think= either of these is technically necessary, but I'l entirely leave the d= ecision about these articles to my co-author :-) =C2=A0(In the first case, = by the way, it's again language contributed by said WG chair. [*])

As a non-native = English speaker, I=E2=80=99ll leave the grammar corrections to you and the = RFC editor (although some ADs tend to engage in that as well)

Which is why I'll need Adam= for these decisions :-)

=
Bodo

=C2=A0

--001a113a5d5e7441d0050d05c270-- From SRS0=tODm=CG=acm.org=bmoeller@srs.kundenserver.de Mon Jan 19 11:56:16 2015 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 EEAA11B2C30; Mon, 19 Jan 2015 11:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ExLp8A1HuiEU; Mon, 19 Jan 2015 11:56:15 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A8C1B2C1B; Mon, 19 Jan 2015 11:56:14 -0800 (PST) Received: from mail-lb0-f182.google.com ([209.85.217.182]) by mrelayeu.kundenserver.de (mreue004) with ESMTPSA (Nemesis) id 0M2pyk-1XvDsj1x3e-00sbF8; Mon, 19 Jan 2015 20:56:11 +0100 Received: by mail-lb0-f182.google.com with SMTP id l4so4578101lbv.13; Mon, 19 Jan 2015 11:56:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.13.103 with SMTP id g7mr16318380lbc.29.1421697370817; Mon, 19 Jan 2015 11:56:10 -0800 (PST) Received: by 10.25.25.145 with HTTP; Mon, 19 Jan 2015 11:56:10 -0800 (PST) In-Reply-To: References: <63164CA2-62C1-4E6C-A3F1-F67F92C26F0F@gmail.com> Date: Mon, 19 Jan 2015 20:56:10 +0100 Message-ID: From: Bodo Moeller To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c39f56c40ca3050d06b63e X-Provags-ID: V03:K0:mRHqYi479MxgY1dExX0NwjBfPeGlZ641PZ93+7FMJX9XIaKWdKK B5fBjIDt6ao9pFs6JUnoSkN7igA2+H59UUStCWm98Xwa3ltHri+C4BY0/OA0gZ3/JMWIcIY WmxDqQrZ0/knVzT/1OyQC54zY2yLElTz6EGuUr8zCtx6xCv1pPtz/yxYWI11IjmIE3qutcm Uhf9gFPBiVX+U/eOXuI3Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "draft-ietf-tls-downgrade-scsv.all@tools.ietf.org" , The IESG , Adam Langley , secdir Subject: Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03 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, 19 Jan 2015 19:57:18 -0000 --001a11c39f56c40ca3050d06b63e Content-Type: text/plain; charset=UTF-8 > A few missing articles: >>> "The fallback SCSV defined in this document is not *a* suitable >>> substitute" >>> "if *the* TLS implementations also include support for (the) predecessor >>> protocol SSL 3.0" >> >> > I don't think either of these is technically necessary, but I'l entirely >> leave the decision about these articles to my co-author :-) >> >> I've just received Russ Housley's Gen-ART review, in which he also asked to change "is not suitable substitute" into "is not a suitable substitute"; so I'll do that. Bodo --001a11c39f56c40ca3050d06b63e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
<= div>
A few missing articles:
"The fallback SCSV defined in this document is not *a* suitable substi= tute"
"if *the* TLS implementations also include support for (the) predecess= or protocol SSL 3.0"
=C2=A0=
I don't think either of thes= e is technically necessary, but I'l entirely leave the decision about t= hese articles to my co-author :-)
<= /span>
=
I've just received Russ Housley= 9;s Gen-ART review, in which he also asked to change "is not suitable = substitute" into "is not a suitable substitute"; so I'll= do that.

Bodo

--001a11c39f56c40ca3050d06b63e-- From nobody Tue Jan 20 13:49:40 2015 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 010C81A0029; Tue, 20 Jan 2015 13:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 HMMhgVWy9bpy; Tue, 20 Jan 2015 13:49:33 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC991A0027; Tue, 20 Jan 2015 13:49:30 -0800 (PST) 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 t0KLnQLd022237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Jan 2015 16:49:27 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_458D4C1B-FE83-4DAA-94B1-9F5EB8646029" Date: Tue, 20 Jan 2015 16:49:26 -0500 Message-Id: <978A8F4D-77E2-4B04-B638-EC321F95D122@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] secdir review of draft-ietf-12vpn-pbb-evpn-09 (resend) 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, 20 Jan 2015 21:49:35 -0000 --Apple-Mail=_458D4C1B-FE83-4DAA-94B1-9F5EB8646029 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I messed up the authors=92 address when I sent this review last week, so = I=92m trying again. Cathy 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 describes a method for integrating Ethernet Provider Backbone = Bridge (PBB) with Ethernet VPN (EVPN) to improve the delivery of MAC addresses, in particular with respect to = scalability. =20 I don=92t see any security concerns with this draft, but I do have some = comments on the Security Considerations section. It is very short, and all it says that the security considerations in = the EVPN draft apply directly to this draft. I assume that it is also the case that this draft introduces no new security = considerations. If so, you should say so, and you should also say why. Also, I was wondering if the mechanisms introduced in = this draft, by introducing a greater degree of organization in the delivery of MAC addresses, makes it easier to detect duplicated = MACs, which were mentioned as a security risk in the Security Considerations of the EVPN draft. If this is the case, it = would be a good thing to mention here. I=92d consider the draft somewhere between ready with nits and ready = with issues. I don=92t see any real security issues here, just a Security Considerations section that needs to be expanded a = little, but this seems to be a little more than what the secdir guidelines would call a nit. 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=_458D4C1B-FE83-4DAA-94B1-9F5EB8646029 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = messed up the authors=92 address when I sent this review last week, so = I=92m
trying = again.

Cathy

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 draft = describes a method for integrating Ethernet Provider Backbone Bridge = (PBB) with Ethernet VPN (EVPN) to
improve the delivery of MAC = addresses, in particular with respect to = scalability.  

I don=92t see any security concerns with = this draft, but I do have some comments on the Security Considerations = section.
It is very short, and all it says that the security = considerations in the EVPN draft apply directly to this draft. I assume = that
it is also the case that this draft introduces no new security = considerations.  If so, you should say so, and you should
also = say why.  Also, I was wondering if the mechanisms introduced in = this draft, by introducing a greater degree of organization
in the = delivery of MAC addresses, makes it easier to detect duplicated MACs, = which were mentioned as a security risk in the
Security = Considerations of the EVPN draft.  If this is the case, it would be = a good thing to mention here.

I=92d consider the draft somewhere = between ready with nits and ready with issues.  I don=92t see any = real security issues
here, just a Security Considerations section = that needs to be expanded a little, but this seems to be a little more = than what the
secdir guidelines would call a nit.
= --Apple-Mail=_458D4C1B-FE83-4DAA-94B1-9F5EB8646029-- From nobody Wed Jan 21 02:39:03 2015 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 CD8021A19F4; Wed, 21 Jan 2015 02:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TvRKvlonQ2Bj; Wed, 21 Jan 2015 02:38:49 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5471A0673; Wed, 21 Jan 2015 02:38:48 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LAckwS002438; Wed, 21 Jan 2015 10:38:46 GMT Received: from 950129200 (089144193178.atnat0002.highway.a1.net [89.144.193.178]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LAchUJ002377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 10:38:44 GMT From: "Adrian Farrel" To: "'Catherine Meadows'" , , , Date: Wed, 21 Jan 2015 10:38:43 -0000 Message-ID: <000001d03566$6ec169d0$4c443d70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D03566.6EC3B3C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA1ZWaEfMjyiXELS/mHwgf0UNsWcA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21270.000 X-TM-AS-Result: No--16.989-10.0-31-10 X-imss-scan-details: No--16.989-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkDP9+wiKyUgQJVRzPxemJL0R0SX1OwlZFqdI/DikZ1UPInV 4FKib7SLBmhTsRS1l4JDnqZ83klHV56U7joP1tmOBfKxbfcZgylA8JZETQujwtCmiQVJO8KAPCp MgiMTEhO3ygdyzB5NhWiz3IFUtmP/YqmUd3tOErVjHWM8krL4PHmzXIkkZMA26ouYUIynB9SkwF TCCpbFRzjWB0c64C3n/BT+yHEF9+/i+TeO1Px/S05GBIYERk6jTLQEUv3ZO7hXPwnnY5XL5K1D1 JxlOmwp9YGm7MUvbd02vCyeqlq0kiz21p1lvsf3sU+l9160C1O/PqtexhSykXjwkzrYHfhD5z25 NZlW0T1rJU9eEeMYc9U7hedAu9sCf/9oLiCflNj9KXlxhBAZb4N12XKYbuJLVxt8iPZNr2yALjq nIlNKdNXjKfop/WvT3wqC9Qsu3hf9+rKlRf1WaEtzk37SzX4NlPV6Vaqi4bDxxaAXDrCns4j7J3 jzONjdJa6rGJR4RfowuiDzT/FFiVHi+vC6FxL8BU4uU+5y12ot0t+aIVLt+5KzWy3+GmBuXM4pV Hn2LwM/makG0+v97t639oRBFUkeQ0pFGvYttetYKMMlFh4BnQEv9fM0UWYfFLXUWU5hGiFdqWvm iTG8mv/55Kkc+9/6c91xMYNqHkWwiaGmybzRh+9vqjAuwk2wkBfdTMRAXUalF7MF/8ayEnii5kS OR4tGVCir/P/HlBCexSLBWoM4BFISCbZIzCBZIj0zFI5DoJJeCrB32KOS0DVeBpP/c9O+4Kt4MZ 4uB8KNIndKSIasU9eS5VWUkyw9nHoiWJ/w7MaeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgM6+WMDQkryviPN6xro6Ww0LoM55fqYUjzdsZhVXX8QuB+3BndfXUhXQ== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-l2vpn-pbb-evpn-09 (resend) 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: Wed, 21 Jan 2015 10:38:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D03566.6EC3B3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Again, re-sending with fixed subject line for people who auto-file. From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Catherine Meadows Sent: 20 January 2015 21:49 To: secdir@ietf.org; iesg@ietf.org; draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org Cc: Catherine Meadows Subject: secdir review of draft-ietf-12vpn-pbb-evpn-09 (resend) I messed up the authors' address when I sent this review last week, so I'm trying again. Cathy 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 draft describes a method for integrating Ethernet Provider Backbone Bridge (PBB) with Ethernet VPN (EVPN) to improve the delivery of MAC addresses, in particular with respect to scalability. I don't see any security concerns with this draft, but I do have some comments on the Security Considerations section. It is very short, and all it says that the security considerations in the EVPN draft apply directly to this draft. I assume that it is also the case that this draft introduces no new security considerations. If so, you should say so, and you should also say why. Also, I was wondering if the mechanisms introduced in this draft, by introducing a greater degree of organization in the delivery of MAC addresses, makes it easier to detect duplicated MACs, which were mentioned as a security risk in the Security Considerations of the EVPN draft. If this is the case, it would be a good thing to mention here. I'd consider the draft somewhere between ready with nits and ready with issues. I don't see any real security issues here, just a Security Considerations section that needs to be expanded a little, but this seems to be a little more than what the secdir guidelines would call a nit. 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 ------=_NextPart_000_0001_01D03566.6EC3B3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Again, re-sending with fixed = subject line for people who auto-file.

 

 

From: iesg = [mailto:iesg-bounces@ietf.org] On Behalf Of Catherine = Meadows
Sent: 20 January 2015 21:49
To: = secdir@ietf.org; iesg@ietf.org; = draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org
Cc: Catherine = Meadows
Subject: secdir review of draft-ietf-12vpn-pbb-evpn-09 = (resend)

 

I messed up the = authors’ address when I sent this review last week, so = I’m

trying = again.

 

Cathy

 

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 draft describes a method for integrating = Ethernet Provider Backbone Bridge (PBB) with Ethernet VPN (EVPN) = to
improve the delivery of MAC addresses, in particular with respect = to scalability.  

I don’t see any security = concerns with this draft, but I do have some comments on the Security = Considerations section.
It is very short, and all it says that the = security considerations in the EVPN draft apply directly to this draft. = I assume that
it is also the case that this draft introduces no new = security considerations.  If so, you should say so, and you = should
also say why.  Also, I was wondering if the mechanisms = introduced in this draft, by introducing a greater degree of = organization
in the delivery of MAC addresses, makes it easier to = detect duplicated MACs, which were mentioned as a security risk in = the
Security Considerations of the EVPN draft.  If this is the = case, it would be a good thing to mention here.

I’d = consider the draft somewhere between ready with nits and ready with = issues.  I don’t see any real security issues
here, just a = Security Considerations section that needs to be expanded a little, but = this seems to be a little more than what the
secdir guidelines would = call a nit.



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

 

------=_NextPart_000_0001_01D03566.6EC3B3C0-- From nobody Thu Jan 22 01:56:59 2015 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 1FE311A1AFA for ; Thu, 22 Jan 2015 01:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 RAD2aPkJm5aC for ; Thu, 22 Jan 2015 01:56:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D731A07BE for ; Thu, 22 Jan 2015 01:56:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t0M9uorR005445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 Jan 2015 11:56:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0M9uoS6013536; Thu, 22 Jan 2015 11:56:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21696.51554.148122.35450@fireball.kivinen.iki.fi> Date: Thu, 22 Jan 2015 11:56:50 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: 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, 22 Jan 2015 09:56:56 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Melinda Shore is next in the rotation. For telechat 2015-01-22 Reviewer LC end Draft David Harrington T 2014-12-24 draft-ietf-tsvwg-sctp-dtls-encaps-08 Sam Hartman T 2015-01-09 draft-farrkingel-pce-abno-architecture-15 Leif Johansson T 2014-12-25 draft-ietf-radext-radius-fragmentation-11 Ben Laurie T 2015-01-08 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 For telechat 2015-02-05 Dorothy Gellert T 2014-12-22 draft-ietf-ippm-rate-problem-09 Tobias Gondrom T 2014-12-18 draft-ietf-mpls-ldp-ipv6-15 Sandy Murphy T 2015-01-28 draft-ietf-httpbis-rfc7238bis-02 Joe Salowey T 2015-02-02 draft-ietf-mpls-seamless-mcast-15 For telechat 2015-02-19 Vincent Roca T 2015-02-04 draft-ietf-mpls-oam-ipv6-rao-02 Yaron Sheffer T 2015-02-04 draft-ietf-tram-turn-third-party-authz-07 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Dan Harkins 2014-12-22 draft-ietf-tsvwg-port-use-06 Jeffrey Hutzelman 2015-01-22 draft-ietf-drinks-spp-protocol-over-soap-07 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Alexey Melnikov 2015-01-14 draft-ietf-opsawg-coman-probstate-reqs-04 Magnus Nystrom 2015-02-13 draft-farrresnickel-harassment-05 Hilarie Orman 2015-02-03 draft-ietf-6man-enhanced-dad-12 Radia Perlman 2015-02-04 draft-ietf-lisp-introduction-10 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2014-12-08 draft-ietf-l3vpn-acceptown-community-09 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 -- kivinen@iki.fi From nobody Thu Jan 22 10:25:05 2015 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 7D0481AD0A3; Thu, 22 Jan 2015 10:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1421951043; bh=s+tXy2OQUH6feAVb0kNaD2qAokVzYyTIN44xb8UsAs0=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=egsov6TRtLUptC0V/vv6rkmNVsumyhba6h2BDsJRcTb+xZfRVReidrwovt/HPKu6l RyIgmLvtDN5Om3QyKTUTdWMGfZCl4Ayeo+wTFmFfLJMa+8W6eYSrqHOMDpSmFcaaE8 43ttwkteX+VQFwv4iQRL62CiRZ+1xPPOmq77up0M= 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 2BEC91AD0A7 for ; Thu, 22 Jan 2015 10:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 kWVdpDR3tzFP for ; Thu, 22 Jan 2015 10:23:59 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5481B1ACEF6 for ; Thu, 22 Jan 2015 10:23:55 -0800 (PST) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith-wifi.sophia.w3.org) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEMQ5-0002hk-RU; Thu, 22 Jan 2015 13:23:54 -0500 To: new-work@ietf.org Date: Thu, 22 Jan 2015 19:23:50 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 22 Jan 2015 10:25:02 -0800 Subject: [secdir] [new-work] Proposed Revised W3C Charter: Multimodal Interaction Working Group (until 2015-02-22) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 18:24:04 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Multimodal Interaction Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft revised charter for the Multimodal Interaction Working Group: https://www.w3.org/2013/10/mmi-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2015-02-22 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Kazuyuki Ashimura, Team Contact and Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] https://www.w3.org/2002/mmi/ [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jan 23 16:26:46 2015 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 313051A87BE; Fri, 23 Jan 2015 14:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1422050948; bh=JH3P6vu0PmNoxInIPPNfz6I+mFd74QpnHPhjrHQagJA=; 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=J+x1V9z46c3RygLzMym0hci8WcQ/LHoDeUcPCC1LCRdgJEczozO6irp4lc6ruXpzi 8iOTLrEkdBEiSL4TwRjnT2wYn1htZRmBTgqI+XSFheKG87RgniPAIfqUpGKvFchngt AZvLCgONNy/vvGvHwnFhJEsxFKwNGHKs7ok0wfgc= 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 CDAE61A8869; Fri, 23 Jan 2015 14:08:43 -0800 (PST) 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 ev7anXjcxSeN; Fri, 23 Jan 2015 14:08:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9CF1A87BE; Fri, 23 Jan 2015 14:08:21 -0800 (PST) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123220821.17662.75544.idtracker@ietfa.amsl.com> Date: Fri, 23 Jan 2015 14:08:21 -0800 Archived-At: 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: X-Mailman-Approved-At: Fri, 23 Jan 2015 16:26:45 -0800 Subject: [secdir] [new-work] WG Review: "Archive" Top-Level Media Type (arcmedia) 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, 23 Jan 2015 22:09:08 -0000 A new IETF working group has been proposed in the Applications Area. 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 2015-02-02. "Archive" Top-Level Media Type (arcmedia) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: arcmedia@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/arcmedia Archive: http://www.ietf.org/mail-archive/web/arcmedia Charter: Archive formats are used to aggregate multiple files and other data into a single object, often with data compression and/or confidentiality protection (encryption). This working group will create an "archive" top-level media type. There has been recent work to register media types for archive formats such as .tar (a POSIX standard format). There are already several similar media types for archive formats, such as .gzip. and .zip. (see, for example, RFC6713), all of which are registered under the top-level media type "application". We create top-level media types only rarely, only with Standards Track RFCs, and only when one or more media types get special (or common, in the case of more than one) handling that does not fit under an existing top-level media type. RFC6838 defines this process. The working group will use draft-seantek-kerwin-arcmedia-type as its initial input for a Standards Track document that creates a top-level media type for archive formats. The document will specify rules for registering subtypes under that new top-level type, considering at a minimum the issue of type suffixes, fragment identifiers, and internationalization. The W3C TAG work on packaging and archives, currently in progress, will also be considered. Either in that same document or in one of more follow-on documents, it will produce an initial set of registrations under the new top-level media type. The main document will include an Implementation Status section, described by RFC6982, to record known projects that will either produce or consume content using the new media type. If by the first milestone there appears to be no implementations of the new media type expected, the working group will conclude, without having produced any RFCs. No other work is in scope for this working group. Milestones: - Jun 2015: Base document - Dec 2015: Registrations document(s) (if separate from the base) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Jan 26 11:49:25 2015 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 9FEFE1AD1BA; Mon, 26 Jan 2015 11:49:20 -0800 (PST) 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 71wrM5L6AC3L; Mon, 26 Jan 2015 11:49:16 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B25B1AD210; Mon, 26 Jan 2015 11:49:14 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u10so9460135lbd.9; Mon, 26 Jan 2015 11:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=iLJMO73M9xG9+GyDHahF8i5wIU+Pk7O4B/kazYABQyk=; b=hVef/kFqBr/U+tS2dCLI2hJeIpIiB1hA1xtY4hinO0rQyH/cPJqOU7bADycqtfcRjw rm6K7NwkxhnSn/Bju2G/16WE5uQnlHWnaBHaUSp2V3wg06sZkKkxoRNX4TjSOLsYlSXB wLn62eWnx5Dxt+bhc0nF4Xa1KnBjZfOtPDYR2r2NWD5WSSTtwf8WA3nJRF/iEYte4p+m ga2c3k5i9uEGCLPH+xhXjKEN6AQ/UFSq64c6hxG/FOYENAPhmTZcQJ/bj/SgOmGaPBUp CXIGBCZ3F70EV8najS7X7KHXTf5dFYk1f6taC+I1If6dFsXrv6BvUem4WrpGoyvAdJ+h zTSA== MIME-Version: 1.0 X-Received: by 10.112.130.65 with SMTP id oc1mr63235lbb.7.1422301753146; Mon, 26 Jan 2015 11:49:13 -0800 (PST) Received: by 10.112.202.65 with HTTP; Mon, 26 Jan 2015 11:49:13 -0800 (PST) Date: Mon, 26 Jan 2015 11:49:13 -0800 Message-ID: From: Radia Perlman To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343318c28147050d936ea3 Archived-At: Cc: The IESG , draft-ietf-list-introduction.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-lisp-introduction-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: Mon, 26 Jan 2015 19:49:20 -0000 --047d7b343318c28147050d936ea3 Content-Type: text/plain; charset=UTF-8 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. LISP (Locator/ID Separation Protocol) is a protocol supporting separating the two functions of IP addresses: node identification and node addressing. It is important in scenarios (like we have today) where organizations own many disjoint ranges of the IP address space causing routing tables to be much bigger than they would have to be if every organization owned a single contiguous space. It also has potential to allow nodes to keep the same IP address for purposes of identification even when their address for purposes of routing changes due to mobility or network reconfiguration. It uses LISP-capable border routers to encapsulate packets and address them to LISP-capable border routers on the other side of the "core Internet". This is an introductory document, where there at least nine other documents specifying details of components used to implement the needed mechanisms. There is a security considerations section, which focuses on a class of denial of service attacks. There are presumably security considerations sections in the other documents, including one that focuses entirely on security, so it is not necessary that all security issues be brought up here. That said, I think that if you were to write an "introduction to security considerations", there are more important ones than the DoS threat. in particular, as a routing protocol care must be taken to make sure a bad actor cannot attract someone else's traffic with mechanisms like those we are trying to address with BGP security. Much of the routing information is maintained in a database "like DNS". If it *were* DNS, DNSSEC could be used to address the integrity issues. If it is home grown, some equivalent mechanism will be necessary. Why not use DNS? Non-Security comments: I assume this document is intended to introduce LISP, and so would logically be the first document that someone wanting to learn about LISP would read. It therefore should point to the other LISP documents for more details but should not depend on them for the purpose of understanding this one. There are a number of concepts that I believe one would have to understand in order to understand LISP and being reading the other documents in the series. I would expect, therefore, that they would be in this document but I could not find them. (If my assumption is incorrect, and there is some other document that should be read before this one, that should be mentioned in the introduction). Section 2. Having no terms defined and referring to reader to check any of nine associated documents is not user friendly. It would be nice if at least one of the documents defined all the terms that were used in more than one document so there would be one place to go for definitions not included in the document being read. EIDs and RLOCs have the same length, appearing to be either IPv4 or IPv6 addresses or perhaps from some other space. Fundamental to understanding LISP is understanding whether they reuse the same values or whether they partition the space into EIDs and RLOCs. This is particularly tricky (and therefore important) in the case of IPv4 addresses, since that space is very densely filled and there would not be room to divide it into two spaces both large enough to accommodate the Internet. Is the expectation that EIDs would be taken from a reserved range (likely the 10.*.*.* range), in which case growth of LISP will be severely constrained during its coexistence phase, or alternately will EIDs use the entire range, in which case it will be difficult or impossible to make LISP nodes interoperate with non-LISP nodes? In a related question, section 3.2 says that EIDs will typically be retrieved from DNS. Is the intent that they be retrieved from A or AAAA records, or from new record types created for LISP. For a LISP node opening a connection to a non-LISP node, will its DNS lookup return a different value than when a non-LISP node is opening a connection to a non-LISP node? How is that made to happen? More detailed questions (that should probably be addressed in order to understand the architecture): Section 3.2 Page 7 item 3: It says that two locators are returned. Is this just an example where there also might only be one locator or there might be 10, or is it always two? If an example, is there some maximum number of addresses (or at least some maximum number likely to be used)? Section 3.3.1: When the UDP header is created, what is used as the source port? Does the decapsulating router (ITR) ignore the outer source IP address and the outer source port, or is there some sort of check done on that information or state established? Typos: Page 9: "An RTR can be thought as a" -> "An RTR can be thought of as a" Page 21: "informations" -> "information" Page 25: "are note used" -> "are not used" --047d7b343318c28147050d936ea3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have review= ed this document as part of the security directorate's ongoingeffort to review all IETF documents being processed by the IESG.= =C2=A0 These
comments were written primarily for the b= enefit of the security area
directors.=C2=A0 Document ed= itors and WG chairs should treat these comments just
lik= e any other last call comments.

LISP (Locator/ID Separation Protocol) is a protocol supp= orting separating
the two functions of IP addresses: nod= e identification and node addressing.
It is important in= scenarios (like we have today) where organizations own
= many disjoint ranges of the IP address space causing routing tables to be
much bigger than they would have to be if every organizat= ion owned a single
contiguous space. It also has potenti= al to allow nodes to keep the same IP
address for purpos= es of identification even when their address for purposes
of routing changes due to mobility or network reconfiguration. It uses<= /span>
LISP-capable border routers to encapsulate packets and a= ddress them to
LISP-capable border routers on the other = side of the "core Internet".

This is an introductory document, where there at = least nine other documents
specifying details of compone= nts used to implement the needed mechanisms.

There is a security considerations sectio= n, which focuses on a class of
denial of service attacks= . There are presumably security considerations
sections = in the other documents, including one that focuses entirely on
security, so it is not necessary that all security issues be brought= up
here. That said, I think that if you were to write a= n "introduction to
security considerations", t= here are more important ones than the DoS threat.
in par= ticular, as a routing protocol care must be taken to make sure a bad=
actor cannot attract someone else's traffic with mechanism= s like those we
are trying to address with BGP security.= Much of the routing information is
maintained in a data= base "like DNS". If it *were* DNS, DNSSEC could be usedto address the integrity issues. If it is home grown, some equiva= lent
mechanism will be necessary.=C2=A0 Why not use DNS?=

Non-Security= comments:

I = assume this document is intended to introduce LISP, and so would logically<= /span>
be the first document that someone wanting to learn abou= t LISP would read.
It therefore should point to the othe= r LISP documents for more details but
should not depend = on them for the purpose of understanding this one. There
are a number of concepts that I believe one would have to understand in
order to understand LISP and being reading the other docum= ents in the
series. I would expect, therefore, that they= would be in this document but I
could not find them. (I= f my assumption is incorrect, and there is some other
do= cument that should be read before this one, that should be mentioned in
the introduction).

Section 2. Having no terms defined and referring to r= eader to check any of
nine associated documents is not u= ser friendly. It would be nice if at least
one of the do= cuments defined all the terms that were used in more than one
document so there would be one place to go for definitions not includ= ed in
the document being read.

EIDs and RLOCs have the same length, a= ppearing to be either IPv4 or IPv6
addresses or perhaps = from some other space. Fundamental to understanding
LISP= is understanding whether they reuse the same values or whether they=
partition the space into EIDs and RLOCs. This is particularly = tricky (and
therefore important) in the case of IPv4 add= resses, since that space is very
densely filled and ther= e would not be room to divide it into two spaces both
la= rge enough to accommodate the Internet. Is the expectation that EIDs would<= /span>
be taken from a reserved range (likely the 10.*.*.* rang= e), in which case
growth of LISP will be severely constr= ained during its coexistence phase, or
alternately will = EIDs use the entire range, in which case it will be
diff= icult or impossible to make LISP nodes interoperate with non-LISP nodes?

In a related qu= estion, section 3.2 says that EIDs will typically be
ret= rieved from DNS. Is the intent that they be retrieved from A or AAAA=
records, or from new record types created for LISP. For a LISP= node opening
a connection to a non-LISP node, will its= DNS lookup return a different
value than when a non-LIS= P node is opening a connection to a non-LISP node?
How i= s that made to happen?
More detailed questions (that should probably be addressed in ord= er to
understand the architecture):

Section 3.2 Page 7 item 3: It say= s that two locators are returned. Is this
just an exampl= e where there also might only be one locator or there might be
10, or is it always two? If an example, is there some maximum number= of
addresses (or at least some maximum number likely to= be used)?

Se= ction 3.3.1: When the UDP header is created, what is used as the source
port? Does the decapsulating router (ITR) ignore the outer = source IP address
and the outer source port, or is there= some sort of check done on that
information or state es= tablished?

Ty= pos:

Page 9: = "An RTR can be thought as a" -> "An RTR can be thought of= as a"

P= age 21: "informations" -> "information"

Page 25: "are note u= sed" -> "are not used"
--047d7b343318c28147050d936ea3-- From nobody Mon Jan 26 13:06:07 2015 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 6D2691AD1DB; Mon, 26 Jan 2015 13:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, 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 iw4l-lE9tNPJ; Mon, 26 Jan 2015 13:05:59 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB7E1A1B20; Mon, 26 Jan 2015 13:05:32 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id x69so9256013oia.10; Mon, 26 Jan 2015 13:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nr23dQODn7tQO6ZOzUM9U8T7sNrXRHZcWQO9rjdIu6w=; b=uDl3VEuevkp0zBm1KrVgC6B7LPII9HZumKEQNrBl7w6tSwxvY3JGDwJaY9/I0chFwU m8p6Ru8tbsfg1MpbevNeX4ieR4KJf02Yk5DHXgApKH5TDltMuLLc6Uu4Ewkjj/aYyCnX Ift6FlYQyFWIoBVmGSzpJmRg1dGwSvKy4jLgt4BEpRWcV4k1x/fZcobJvil7hgZhbvjQ iWKbZ6zhrQa0x6X9bjkXZyHO2M+TQuektafO3rAKl6G8RSw5MSyg38By2lSnpViW8iOc rY+4QdSsManasvAS09iU7nYRDeAkGcMC5K8yPGharKuW0nxlvVVJZqrgnUsjg3zASFsc W9XA== MIME-Version: 1.0 X-Received: by 10.182.27.241 with SMTP id w17mr13817351obg.14.1422306330814; Mon, 26 Jan 2015 13:05:30 -0800 (PST) Received: by 10.202.135.17 with HTTP; Mon, 26 Jan 2015 13:05:30 -0800 (PST) In-Reply-To: <54C67136.8090908@crf.canon.fr> References: <54C67136.8090908@crf.canon.fr> Date: Mon, 26 Jan 2015 16:05:30 -0500 Message-ID: From: Matthew Lepinski To: =?UTF-8?Q?Herv=C3=A9_Ruellan?= Content-Type: multipart/alternative; boundary=001a113345c69c2d27050d947fb9 Archived-At: Cc: draft-ietf-httpbis-header-compression.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR Review of draft-ietf-httpbis-header-compression-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: Mon, 26 Jan 2015 21:06:02 -0000 --001a113345c69c2d27050d947fb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks a lot. 706 looks good. It is a small change, but I think it will be helpful. On Mon, Jan 26, 2015 at 11:54 AM, Herv=C3=A9 Ruellan wrote: > Hi Matthew, > > > On 01/19/2015 04:46 AM, Matthew Lepinski wrote: > >> I have reviewed this document as part of the security directorate=E2=80= =99s >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written with the intent of improving security >> requirements and considerations in IETF drafts. Comments not addressed >> in last call may be included in AD reviews during the IESG review. >> Document editors and WG chairs should treat these comments just like any >> other last call comments. >> >> This document specifies HPACK, the compression scheme used by HTTP/2. A >> new compression scheme was needed for HTTP/2 because of attacks against >> systems where traditional compression schemes were used to compress HTTP >> headers sent over an encrypted TLS connection. (e.g., the CRIME attack >> against SPDY.) HPACK is specifically designed to avoid CRIME and similar >> attacks. >> >> I believe that this document is mature and nearly ready for publication. >> However, I have one concern and would request a change to the document >> (see below). >> >> After reviewing this document and looking at the PETAL paper it >> references, I am satisfied that -- as the authors claim -- the HPACK >> scheme [when used to compress HTTP headers] is secure relative to our >> (the security community) current understanding of attacks against >> encryption of compressed data. That is, I believe that the authors have >> adequately addressed -- in the design of HPACK and the associated >> Security Considerations section -- all known security issues. >> >> That being said, since HPACK is a relatively new algorithm, and since >> encryption of compressed headers is known to be somewhat perilous, it is >> possible that a clever attacker will develop a new attack in the future >> (i.e., CRIME++ ) that works against HPACK-compressed header fields. I >> haven't read the latest version of HTTP/2 carefully enough to know >> whether HTTP/2 has a mechanism for an implementation to turn off use of >> HPACK if such an attack is discovered. However, planning for a possible >> future attack against HPACK would probably be wise. >> > > While it's not possible to turn off use of HPACK from HTTP/2, it is > possible to not use any indexing into HPACK resulting in encoding all > values as literals. This is the fallback if ever HPACK is compromised. > > =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 >> REQUEST FOR CHANGE TO: draft-ietf-httpbis-header-compression >> >> The Security Considerations in this document are extremely well-written >> (particularly Sections 7.1.1 and 7.1.2). Based on experience with the >> CRIME attack, there are significant security concerns (described in >> Section 7.1) with encrypting compressed headers. Section 7.1.1 explains >> how these concerns relate to HPACK and Section 7.1.2 describes steps >> that an HPACK encoder implementation can take to mitigate these >> concerns. These sections are very important -- indeed, more important >> than the security considerations sections for many IETF documents. >> >> I would very much like to see a forward reference to Section 7.1.2 (or >> perhaps just Section 7.1 as whole) at some point earlier in the document >> when the authors are describing the encoder (probably somewhere in >> Section 2). That is, there are important mitigation techniques that an >> implementer should have in mind when creating an HPACK encoder. I >> believe that referencing these techniques when the encoding process is >> described would be a good idea. >> > > I added pointers to the security sections in: > https://github.com/http2/http2-spec/pull/706 > > =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 >> > > Herv=C3=A9. > --001a113345c69c2d27050d947fb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks a lot.=C2=A0

706 looks good. It = is a small change, but I think it will be helpful.

On Mon, Jan 26, 2015 at 11:54 = AM, Herv=C3=A9 Ruellan <herve.ruellan@crf.canon.fr>= wrote:
Hi Matthew,


On 01/19/2015 04:46 AM, Matthew Lepinski wrote:
I have reviewed this document as part of the security directorate=E2=80=99s=
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written with the intent of improving securi= ty
requirements and considerations in IETF drafts.=C2=A0 Comments not addresse= d
in last call may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments just like any other last call comments.

This document specifies HPACK, the compression scheme used by HTTP/2. A
new compression scheme was needed for HTTP/2 because of attacks against
systems where traditional compression schemes were used to compress HTTP headers sent over an encrypted TLS connection. (e.g., the CRIME attack
against SPDY.) HPACK is specifically designed to avoid CRIME and similar attacks.

I believe that this document is mature and nearly ready for publication. However, I have one concern and would request a change to the document
(see below).

After reviewing this document and looking at the PETAL paper it
references, I am satisfied that -- as the authors claim -- the HPACK
scheme [when used to compress HTTP headers] is secure relative to our
(the security community) current understanding of attacks against
encryption of compressed data. That is, I believe that the authors have
adequately addressed -- in the design of HPACK and the associated
Security Considerations section -- all known security issues.

That being said, since HPACK is a relatively new algorithm, and since
encryption of compressed headers is known to be somewhat perilous, it is possible that a clever attacker will develop a new attack in the future
(i.e., CRIME++ ) that works against HPACK-compressed header fields. I
haven't read the latest version of HTTP/2 carefully enough to know
whether HTTP/2 has a mechanism for an implementation to turn off use of
HPACK if such an attack is discovered. However, planning for a possible
future attack against HPACK would probably be wise.

While it's not possible to turn off use of HPACK from HTTP/2, it is pos= sible to not use any indexing into HPACK resulting in encoding all values a= s literals. This is the fallback if ever HPACK is compromised.

=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
REQUEST FOR CHANGE TO: draft-ietf-httpbis-header-compression

The Security Considerations in this document are extremely well-written
(particularly Sections 7.1.1 and 7.1.2). Based on experience with the
CRIME attack, there are significant security concerns (described in
Section 7.1) with encrypting compressed headers. Section 7.1.1 explains
how these concerns relate to HPACK and Section 7.1.2 describes steps
that an HPACK encoder implementation can take to mitigate these
concerns. These sections are very important -- indeed, more important
than the security considerations sections for many IETF documents.

I would very much like to see a forward reference to Section 7.1.2 (or
perhaps just Section 7.1 as whole) at some point earlier in the document =C2=A0 when the authors are describing the encoder (probably somewhere in Section 2). That is, there are important mitigation techniques that an
implementer should have in mind when creating an HPACK encoder. I
believe that referencing these techniques when the encoding process is
described would be a good idea.

 I added pointers to the security sections in:
= https://github.com/http2/http2-spec/pull/706

=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

Herv=C3=A9.

--001a113345c69c2d27050d947fb9-- From nobody Tue Jan 27 08:18:41 2015 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 CAEF81ACCDE; Mon, 26 Jan 2015 08:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 aSjeimofCWim; Mon, 26 Jan 2015 08:54:19 -0800 (PST) Received: from inari-msr.crf.canon.fr (inari-msr.crf.canon.fr [194.2.158.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA6F1ACCE4; Mon, 26 Jan 2015 08:54:18 -0800 (PST) Received: from mir-bsr.corp.crf.canon.fr (mir-bsr.corp.crf.canon.fr [172.19.77.99]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id t0QGsG6s028686; Mon, 26 Jan 2015 17:54:16 +0100 Received: from Antiope.crf.canon.fr (antiope.fesl2.crf.canon.fr [172.19.70.56]) by mir-bsr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id t0QGsGA7017638; Mon, 26 Jan 2015 17:54:16 +0100 Received: from timor.intra-usr.crf.canon.fr (172.20.3.149) by Antiope.crf.canon.fr (172.19.70.56) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 26 Jan 2015 17:54:14 +0100 Message-ID: <54C67136.8090908@crf.canon.fr> Date: Mon, 26 Jan 2015 17:54:14 +0100 From: =?UTF-8?B?SGVydsOpIFJ1ZWxsYW4=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Matthew Lepinski , "secdir@ietf.org" , "iesg@ietf.org" , References: In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.3.149] X-ClientProxiedBy: Antiope.crf.canon.fr (172.19.70.56) To Antiope.crf.canon.fr (172.19.70.56) Archived-At: X-Mailman-Approved-At: Tue, 27 Jan 2015 08:18:40 -0800 Subject: Re: [secdir] SECDIR Review of draft-ietf-httpbis-header-compression-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: Mon, 26 Jan 2015 16:54:21 -0000 Hi Matthew, On 01/19/2015 04:46 AM, Matthew Lepinski 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 with the intent of improving security > requirements and considerations in IETF drafts. Comments not addressed > in last call may be included in AD reviews during the IESG review. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > This document specifies HPACK, the compression scheme used by HTTP/2. A > new compression scheme was needed for HTTP/2 because of attacks against > systems where traditional compression schemes were used to compress HTTP > headers sent over an encrypted TLS connection. (e.g., the CRIME attack > against SPDY.) HPACK is specifically designed to avoid CRIME and similar > attacks. > > I believe that this document is mature and nearly ready for publication. > However, I have one concern and would request a change to the document > (see below). > > After reviewing this document and looking at the PETAL paper it > references, I am satisfied that -- as the authors claim -- the HPACK > scheme [when used to compress HTTP headers] is secure relative to our > (the security community) current understanding of attacks against > encryption of compressed data. That is, I believe that the authors have > adequately addressed -- in the design of HPACK and the associated > Security Considerations section -- all known security issues. > > That being said, since HPACK is a relatively new algorithm, and since > encryption of compressed headers is known to be somewhat perilous, it is > possible that a clever attacker will develop a new attack in the future > (i.e., CRIME++ ) that works against HPACK-compressed header fields. I > haven't read the latest version of HTTP/2 carefully enough to know > whether HTTP/2 has a mechanism for an implementation to turn off use of > HPACK if such an attack is discovered. However, planning for a possible > future attack against HPACK would probably be wise. While it's not possible to turn off use of HPACK from HTTP/2, it is possible to not use any indexing into HPACK resulting in encoding all values as literals. This is the fallback if ever HPACK is compromised. > ========================== > REQUEST FOR CHANGE TO: draft-ietf-httpbis-header-compression > > The Security Considerations in this document are extremely well-written > (particularly Sections 7.1.1 and 7.1.2). Based on experience with the > CRIME attack, there are significant security concerns (described in > Section 7.1) with encrypting compressed headers. Section 7.1.1 explains > how these concerns relate to HPACK and Section 7.1.2 describes steps > that an HPACK encoder implementation can take to mitigate these > concerns. These sections are very important -- indeed, more important > than the security considerations sections for many IETF documents. > > I would very much like to see a forward reference to Section 7.1.2 (or > perhaps just Section 7.1 as whole) at some point earlier in the document > when the authors are describing the encoder (probably somewhere in > Section 2). That is, there are important mitigation techniques that an > implementer should have in mind when creating an HPACK encoder. I > believe that referencing these techniques when the encoding process is > described would be a good idea. I added pointers to the security sections in: https://github.com/http2/http2-spec/pull/706 > ========================== Hervé. From nobody Thu Jan 29 02:17:02 2015 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 EFC3A1A0151 for ; Thu, 29 Jan 2015 02:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 SS2SFIZITLLf for ; Thu, 29 Jan 2015 02:16:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F191A0193 for ; Thu, 29 Jan 2015 02:16:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t0TAGlCp002878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 29 Jan 2015 12:16:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t0TAGlwh011143; Thu, 29 Jan 2015 12:16:47 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21706.2191.83782.878835@fireball.kivinen.iki.fi> Date: Thu, 29 Jan 2015 12:16:47 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: 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, 29 Jan 2015 10:16:57 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sam Weiler is next in the rotation. For telechat 2015-02-05 Reviewer LC end Draft Dorothy Gellert T 2014-12-22 draft-ietf-ippm-rate-problem-09 Tobias Gondrom T 2014-12-18 draft-ietf-mpls-ldp-ipv6-15 Sandy Murphy T 2015-01-28 draft-ietf-httpbis-rfc7238bis-02 Joe Salowey T 2015-02-02 draft-ietf-mpls-seamless-mcast-15 Sam Weiler T 2014-12-08 draft-ietf-l3vpn-acceptown-community-09 For telechat 2015-02-19 Dan Harkins T 2014-12-22 draft-ietf-tsvwg-port-use-07 Alexey Melnikov T 2015-01-14 draft-ietf-opsawg-coman-probstate-reqs-04 Vincent Roca T 2015-02-04 draft-ietf-mpls-oam-ipv6-rao-02 Yaron Sheffer T 2015-02-04 draft-ietf-tram-turn-third-party-authz-08 Takeshi Takahashi T 2015-02-17 draft-ietf-calext-rscale-03 David Waltermire T 2015-02-10 draft-ietf-uta-tls-bcp-08 For telechat 2015-03-05 Melinda Shore T 2015-02-24 draft-faltstrom-uri-10 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman 2015-01-22 draft-ietf-drinks-spp-protocol-over-soap-07 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Magnus Nystrom 2015-02-13 draft-farrresnickel-harassment-05 Hilarie Orman 2015-02-03 draft-ietf-6man-enhanced-dad-12 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2015-02-09 draft-ietf-ippm-ipsec-08 Tina TSOU 2015-02-09 draft-ietf-kitten-gss-loop-04 Sean Turner 2015-02-06 draft-ietf-mif-mpvd-arch-09 Carl Wallace 2015-02-10 draft-ietf-netext-ani-location-07 Paul Wouters 2014-12-04 draft-ietf-tcpm-accecn-reqs-07 -- kivinen@iki.fi From nobody Thu Jan 29 11:36:05 2015 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 A845D1A6FEF; Thu, 29 Jan 2015 11:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, 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 z-zxg7CXsn9t; Thu, 29 Jan 2015 11:36:00 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728A21A6F33; Thu, 29 Jan 2015 11:35:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,487,1418079600"; d="scan'208";a="119406641" Received: from anice-152-1-52-170.w86-193.abo.wanadoo.fr (HELO mbp-de-vincent.lan) ([86.193.91.170]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 29 Jan 2015 20:35:55 +0100 From: Vincent Roca Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jan 2015 20:35:52 +0100 Message-Id: <53F9995B-6F70-49D2-ABA1-AD293C185121@inria.fr> To: IESG , secdir@ietf.org, draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [secdir] Secdir review of draft-ietf-mpls-oam-ipv6-rao-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: Thu, 29 Jan 2015 19:36:01 -0000 Hello, I have reviewed this document as part of the security directorate=92s = 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. Summary: ready This document specifies a new Router Alert Option Value for IPv6, to be = used by MPLS OAM tools in IPv6 environments. It does not introduce any new mechanism that is likely to create = security threats. Additionally, RFC 6398 discusses the security aspects of IP = Router Alert in detail. The Security Considerations section of the present = document refers to this (and related RFCs) for security aspects which I think is = appropriate. Non-Security comments: ** The Introduction uses several terms that appear to me synonymous, = namely: generic Option Value generic IPV6 Router Alert code point Value field in the Router Alert Option IPv6 Router Alert Option Value And later in Section 3: option value (i.e., without any upper case letter) Or in Section 6: defines a new code point (value TBD1) It's worth to harmonize them. ** Section 5: there's probably a missing word in: "...examine the packet the MPLS OAM purpose."= From nobody Thu Jan 29 11:50:13 2015 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 A43DD1A7005; Thu, 29 Jan 2015 11:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.9 X-Spam-Level: X-Spam-Status: No, score=-103.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 S6Q_Ln6baBPU; Thu, 29 Jan 2015 11:50:05 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514A41A7004; Thu, 29 Jan 2015 11:50:05 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0TJo3ng025070; Thu, 29 Jan 2015 19:50:03 GMT Received: from 950129200 (194-166-224-30.adsl.highway.telekom.at [194.166.224.30]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0TJo1qx025057 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2015 19:50:02 GMT From: "Adrian Farrel" To: "'Vincent Roca'" , "'IESG'" , , References: <53F9995B-6F70-49D2-ABA1-AD293C185121@inria.fr> In-Reply-To: <53F9995B-6F70-49D2-ABA1-AD293C185121@inria.fr> Date: Thu, 29 Jan 2015 19:50:00 -0000 Message-ID: <00f101d03bfc$c5708f30$5051ad90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIBcNoYGZtvoWVneyalyEOIazxr5Jx1Fljw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21292.002 X-TM-AS-Result: No--11.628-10.0-31-10 X-imss-scan-details: No--11.628-10.0-31-10 X-TMASE-MatchedRID: HXSqh3WYKfunykMun0J1wvHkpkyUphL9Ud7Bjfo+5jQ5CCUkHUNu7iTC VwyY5KnU9yVWMX78LNQbyBySNUwX/qfvoMzwlFfiF6z9HGHKwNsyGiaSs0n67M1BXOF9hjmy48f E6PIFskDswJyg33osayJaS+qP0e8yrE+g6/fP28kmZusHWPhfCnN3sLsG0mhuh/BqejSDeoK8xJ mJORcY9PIdglT1fbSdbKDjm1aK3I3EQS2ecfkpFyVypP66BP0QfS0Ip2eEHny+qryzYw2E8M894 3oc3p3sq7rFUcuGp/EgBwKKRHe+r1x3Klt/+HKxUpJLpaHrWyiUOTGH9lzUggEnFQ04RFTIt9f1 B/BFlEo= Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-mpls-oam-ipv6-rao-02 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, 29 Jan 2015 19:50:07 -0000 Thanks Vincent. Good nits. Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Vincent Roca > Sent: 29 January 2015 19:36 > To: IESG; secdir@ietf.org; draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org > Cc: Vincent Roca > Subject: Secdir review of draft-ietf-mpls-oam-ipv6-rao-02 > > Hello, > > 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. > > Summary: ready > > This document specifies a new Router Alert Option Value for IPv6, to be used > by MPLS OAM tools in IPv6 environments. > It does not introduce any new mechanism that is likely to create security > threats. Additionally, RFC 6398 discusses the security aspects of IP Router > Alert in detail. The Security Considerations section of the present document > refers to this (and related RFCs) for security aspects which I think is appropriate. > > > Non-Security comments: > > ** The Introduction uses several terms that appear to me synonymous, namely: > generic Option Value > generic IPV6 Router Alert code point > Value field in the Router Alert Option > IPv6 Router Alert Option Value > And later in Section 3: > option value (i.e., without any upper case letter) > Or in Section 6: > defines a new code point (value TBD1) > It's worth to harmonize them. > > ** Section 5: there's probably a missing word in: > "...examine the packet the MPLS OAM purpose." From nobody Fri Jan 30 06:26:47 2015 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 06CD61A9067; Fri, 30 Jan 2015 06:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLxe9Qm6aA4g; Fri, 30 Jan 2015 06:26:43 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8384C1A9066; Fri, 30 Jan 2015 06:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2730; q=dns/txt; s=iport; t=1422628003; x=1423837603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zD7ImfQ6mK+1q6j8tav7NAbzW9VRLqoipZ9dewjzreI=; b=MWcFm5t9jcFAL2ZRsl+7o1lesByp/rq+jTB4HW9npIntdaeuOk0ODx3/ GdCs6qDx/yOcrSOHlA58gA6/6viQQzlR0CK0B97/9FLXf1DEbgPrllryi pAlAzVwW2q2VfR6oi1R4Ol1DOt05Ol16xr2K/lPowRohy8Ur2tS/43KMU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CABQBkk8tU/5ldJa1agmQigSsEgn2/SIgWAhyBAUMBAQEBAX2EDAEBAQMBIxFFBQcEAgEIEQQBAQECAiMDAgICMBQBCAgCBA4FiCQIAcEQlX4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGOJDMHBoJiLoETAQSOfIkiklEig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,491,1418083200"; d="scan'208";a="119038223" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 30 Jan 2015 14:26:42 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0UEQgF4028894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 14:26:42 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 08:26:42 -0600 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: Secdir review of draft-ietf-mpls-oam-ipv6-rao-02 Thread-Index: AQHQO/rWH+CYXFr8DUaiFa8Y0LuXwpzX5icAgAE3/4A= Date: Fri, 30 Jan 2015 14:26:40 +0000 Message-ID: References: <53F9995B-6F70-49D2-ABA1-AD293C185121@inria.fr> <00f101d03bfc$c5708f30$5051ad90$@olddog.co.uk> In-Reply-To: <00f101d03bfc$c5708f30$5051ad90$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.53.173] Content-Type: text/plain; charset="utf-8" Content-ID: <414DEEFBBC5142498FBD84CB1B3A81F7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IESG , "draft-ietf-mpls-oam-ipv6-rao@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-oam-ipv6-rao-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, 30 Jan 2015 14:26:45 -0000 VGhhbmtzIGluZGVlZCwgVmluY2VudC4gDQoNCkFkcmlhbiwgd2UgZml4ZWQgdGhlc2UgdHdvIG5p dHMgaW4gb3VyIHdvcmtpbmcgY29weS4NCg0KVGhhbmtzLA0KDQrigJQgQ2FybG9zLg0KDQo+IE9u IEphbiAyOSwgMjAxNSwgYXQgMjo1MCBQTSwgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5j by51az4gd3JvdGU6DQo+IA0KPiBUaGFua3MgVmluY2VudC4gR29vZCBuaXRzLg0KPiBBZHJpYW4N Cj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogaWVzZyBbbWFpbHRv Omllc2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpbmNlbnQgUm9jYQ0KPj4gU2Vu dDogMjkgSmFudWFyeSAyMDE1IDE5OjM2DQo+PiBUbzogSUVTRzsgc2VjZGlyQGlldGYub3JnOyBk cmFmdC1pZXRmLW1wbHMtb2FtLWlwdjYtcmFvQHRvb2xzLmlldGYub3JnDQo+PiBDYzogVmluY2Vu dCBSb2NhDQo+PiBTdWJqZWN0OiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBscy1vYW0t aXB2Ni1yYW8tMDINCj4+IA0KPj4gSGVsbG8sDQo+PiANCj4+IEkgaGF2ZSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0K Pj4gZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5 IHRoZSBJRVNHLiBUaGVzZQ0KPj4gY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4+IGRpcmVjdG9ycy4gIERvY3VtZW50 IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0K Pj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPj4gDQo+PiBTdW1tYXJ5OiBy ZWFkeQ0KPj4gDQo+PiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBSb3V0ZXIgQWxlcnQg T3B0aW9uIFZhbHVlIGZvciBJUHY2LCB0byBiZSB1c2VkDQo+PiBieSBNUExTIE9BTSB0b29scyBp biBJUHY2IGVudmlyb25tZW50cy4NCj4+IEl0IGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IG1l Y2hhbmlzbSB0aGF0IGlzIGxpa2VseSB0byBjcmVhdGUgc2VjdXJpdHkNCj4+IHRocmVhdHMuIEFk ZGl0aW9uYWxseSwgUkZDIDYzOTggZGlzY3Vzc2VzIHRoZSBzZWN1cml0eSBhc3BlY3RzIG9mIElQ IFJvdXRlcg0KPj4gQWxlcnQgaW4gZGV0YWlsLiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg c2VjdGlvbiBvZiB0aGUgcHJlc2VudCBkb2N1bWVudA0KPj4gcmVmZXJzIHRvIHRoaXMgKGFuZCBy ZWxhdGVkIFJGQ3MpIGZvciBzZWN1cml0eSBhc3BlY3RzIHdoaWNoIEkgdGhpbmsgaXMNCj4gYXBw cm9wcmlhdGUuDQo+PiANCj4+IA0KPj4gTm9uLVNlY3VyaXR5IGNvbW1lbnRzOg0KPj4gDQo+PiAq KiBUaGUgSW50cm9kdWN0aW9uIHVzZXMgc2V2ZXJhbCB0ZXJtcyB0aGF0IGFwcGVhciB0byBtZSBz eW5vbnltb3VzLCBuYW1lbHk6DQo+PiAgICAgICBnZW5lcmljIE9wdGlvbiBWYWx1ZQ0KPj4gICAg ICAgZ2VuZXJpYyBJUFY2IFJvdXRlciBBbGVydCBjb2RlIHBvaW50DQo+PiAgICAgICBWYWx1ZSBm aWVsZCBpbiB0aGUgUm91dGVyIEFsZXJ0IE9wdGlvbg0KPj4gICAgICAgSVB2NiBSb3V0ZXIgQWxl cnQgT3B0aW9uIFZhbHVlDQo+PiBBbmQgbGF0ZXIgaW4gU2VjdGlvbiAzOg0KPj4gICAgICAgb3B0 aW9uIHZhbHVlICAgICAgICAgICAgKGkuZS4sIHdpdGhvdXQgYW55IHVwcGVyIGNhc2UgbGV0dGVy KQ0KPj4gT3IgaW4gU2VjdGlvbiA2Og0KPj4gICAgICAgZGVmaW5lcyBhIG5ldyBjb2RlIHBvaW50 ICh2YWx1ZSBUQkQxKQ0KPj4gSXQncyB3b3J0aCB0byBoYXJtb25pemUgdGhlbS4NCj4+IA0KPj4g KiogU2VjdGlvbiA1OiB0aGVyZSdzIHByb2JhYmx5IGEgbWlzc2luZyB3b3JkIGluOg0KPj4gICAg ICAgIi4uLmV4YW1pbmUgdGhlIHBhY2tldCB0aGUgTVBMUyBPQU0gcHVycG9zZS4iDQo+IA0KDQo= From nobody Fri Jan 30 16:04:21 2015 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 CC99C1A87E0; Fri, 30 Jan 2015 16:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 0xj5RSwq2pv7; Fri, 30 Jan 2015 16:04:10 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 774C91A87E1; Fri, 30 Jan 2015 16:04:10 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1A6F310224008; Fri, 30 Jan 2015 16:04:10 -0800 (PST) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 30 Jan 2015 16:04:10 -0800 (PST) Message-ID: <950ad656ed2a0e36e24fd7dc0e2b60b1.squirrel@www.trepanning.net> Date: Fri, 30 Jan 2015 16:04:10 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-port-use.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [secdir] secdir review of draft-ietf-tsvwg-port-use 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: Sat, 31 Jan 2015 00:04:12 -0000 Hello, 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 draft provides some advice and recommendations on protocol port use to application and service designers. It has a nice, brief history of port usage and a nice list of guiding principles to help conserve port space. It will make a nice BCP. In my opinion it is Ready For Publication. With that said, I do have a small comment. In section 7.4 the draft says that TLS should be used to protect services that do not provide their own security directly. It might be worth while adding mention of DTLS and IPsec. And if the latter is not something that should be recommended then justification for that stance should be given. regards, Dan.