From nobody Mon Mar 2 06:55: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 4832F1A87D7 for ; Mon, 2 Mar 2015 06:55:08 -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 ZQxS6rgrQPRE for ; Mon, 2 Mar 2015 06:55:06 -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 10C7F1A87C1 for ; Mon, 2 Mar 2015 06:55:05 -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 t22Et1wW012641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 2 Mar 2015 16:55:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t22Et1Fk001088; Mon, 2 Mar 2015 16:55:01 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21748.31172.981305.579910@fireball.kivinen.iki.fi> Date: Mon, 2 Mar 2015 16:55:00 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 6 min X-Total-Time: 5 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: Mon, 02 Mar 2015 14:55:08 -0000 Because of my vacation I was not able to do assignments for last few weeks, so some of these reviews have VERY short time to be completed. I hope people are still able to do the reviews even when the telechat is already in this week. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Simon Josefsson is next in the rotation. For telechat 2015-03-05 Alan DeKok T 2015-02-18 draft-ietf-teas-rsvp-te-li-lb-04 Donald Eastlake T 2015-02-20 draft-ietf-6tisch-tsch-05 Olafur Gudmundsson T 2015-03-05 draft-ietf-bfcpbis-rfc4582bis-13 Phillip Hallam-Baker T 2015-03-03 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-09 Steve Hanna T 2015-03-03 draft-ietf-stox-chat-10 David Harrington T 2015-03-03 draft-ietf-mpls-lsp-ping-registry-02 Jeffrey Hutzelman T 2015-03-03 draft-ietf-stox-im-12 Leif Johansson T 2015-03-03 draft-ietf-stox-groupchat-10 Carl Wallace T 2015-02-10 draft-ietf-netext-ani-location-08 For telechat 2015-03-12 Dave Cridland T 2015-02-18 draft-ietf-teas-lsp-attribute-ro-03 Dan Harkins T 2015-03-04 draft-ietf-dhc-dhcpv6-stateful-issues-11 Paul Hoffman T 2015-03-12 draft-ietf-idr-error-handling-18 Chris Inacio T 2015-03-10 draft-ietf-pim-rfc4601bis-04 Melinda Shore T 2015-02-24 draft-faltstrom-uri-11 Last calls and special requests: Dorothy Gellert 2015-02-23 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-06 Tobias Gondrom 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-04 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Sam Hartman 2015-03-11 draft-ietf-netconf-rfc5539bis-09 Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 Radia Perlman R2015-03-09 draft-ietf-lmap-framework-11 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2015-02-16 draft-ietf-6man-resilient-rs-04 -- kivinen@iki.fi From nobody Mon Mar 2 10:16: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 F11931A8724; Mon, 2 Mar 2015 10:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 2Xhy7dHVh5sv; Mon, 2 Mar 2015 10:16:13 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 301601A87C9; Mon, 2 Mar 2015 10:16:11 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t22IG8mp005362 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 2 Mar 2015 19:16:08 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id t22IG42j002106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 19:16:06 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1425320167; bh=ca33HN2CEL65HPm6LHjizNgvGhlJ9t929F5Sbv4jySc=; h=Date:From:To:Subject; b=UHm+zc9MzcQF47Ra3CNUM+2qFjvUo//3jusM1KOsIiI8ZYYitlEXY9qSrxCPyeYsJ rllNF6HzAN7z//qQzAUmdAAzbHRp3fCikTapqTPRx5JPdlv8lK2LDRJvHGSDnn2OCu 8bYVe7YY8Xcy7Vu5OZE1AJooMZs9qEgGO1PWGkjI= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.4 patch 1) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)); Mon, 2 Mar 2015 19:16:04 +0100 Message-ID: <54F4A8E3.1010802@sunet.se> Date: Mon, 02 Mar 2015 19:16:03 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: draft-ietf-stox-groupchat.all@tools.ietf.org, "secdir@ietf.org" , IESG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09NWGg8X6 - 45eda613d5ab - 20150302 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: [secdir] secdir review of draft-ietf-stox-groupchat-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, 02 Mar 2015 18:16:16 -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 imo as ready as it is likely to be from a security perspective. The security considerations section does contain an I-D reference (draft-ietf-simple-chat) which needs to be resolved before publication though. Leif From nobody Mon Mar 2 12:18:45 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 7736A1A897A for ; Mon, 2 Mar 2015 12:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 JTGT_r8wiTFq for ; Mon, 2 Mar 2015 12:18:43 -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 C51A91A8981 for ; Mon, 2 Mar 2015 12:18:43 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t22KIgwC002338 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Mar 2015 13:18:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <14C0D5BD-5063-4B8F-B17F-80C9A832AC75@vpnc.org> Date: Mon, 2 Mar 2015 12:18:42 -0800 To: secdir Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [secdir] Secdir review of draft-ietf-idr-error-handling 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, 02 Mar 2015 20:18:44 -0000 Greetings again. This document updates the error handling of a bunch of = BGP protocol documents to deal with the fact that they (inadvertently) = allow a remote attacker to cause BGP sessions to be reset when they = probably shouldn't be. The problem being solved is that BGP says that if = an UPDATE message with a malformed attribute is received, the current = spec says the entire session in which that message was received is = reset, even parts that are valid. However, UPDATE messages might be = propagated through intermediate routers that don't check the attribute = validity, so that an attacker can possibly make a hard-to-trace and = expanding attack. The draft says, in essence, "limit the damage of the malformed attribute = to only the part of the session that are directly related to it". It = also updates the similar error handing for a bunch of other BGP = attributes. Overall, the draft is clear, and the Security Considerations = section is concise and easy to understand. --Paul Hoffman= From nobody Mon Mar 2 14:27: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 4CEE71A8A56; Mon, 2 Mar 2015 14:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr50ql2KeS7b; Mon, 2 Mar 2015 14:27:25 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0955B1A8A55; Mon, 2 Mar 2015 14:27:22 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Mon, 2 Mar 2015 17:27:17 -0500 Message-ID: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C4_01D0550E.2275E840" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBVMeb8nh8z8cJJR6SPdF4VwHGdeQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , secdir@ietf.org Subject: [secdir] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 02 Mar 2015 22:27:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C4_01D0550E.2275E840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS WG: We are trying to wrap of the protocol requirements for I2RS within March. This post ask 3 questions regarding the I2RS requirements. Question 1 context: The I2RS architecture states in section 1.1 that the I2RS interface should be: programmatic, asynchronous, and offers fast, interactive access for atomic operations. This posts asks if we need to require a checkpoint to make asynchronous functions work. In a review by the security directorate, the reviewer asked: "Is security and the support for the asynchronous nature of the protocol fully supported?" In the reviewers mind Asynchronous usually means the following: 1) The protocol can launch operations and then check back later whether they successfully completed. 2) If you want to execute a second operation only if a first succeeds (or to guarantee the order in which they execute), you need to at some point wait for operations to complete. 3) There is also substantial overhead in supporting asynchronous operation in that all transactions need labels so that they can be queried? Question 1: Do we believe that netconf or restconf augmented by the traceability requirements and the pub/sub requirements provides this support? Question 2: Do we need a checkpoint (monotonically incrementing counter to accomplish #2)? Question 3 Context: The security directorate reviewer of the I2RS architecture stated: " A conceptually simpler strategy [than the asynchronous strategy] is to say that since a client can make multiple parallel connections to an agent that in cases where a client wants asynchronous operation he opens multiple connections and launches one asynchronous operation on each. The cost is that is has lower performance in cases where there are large numbers of parallel operations tying up lots of connection state." In my understanding RESTCONF provides one operations per session. Question 3: If the I2RS client requires a tradeoff where that restricts the space requirements for parallel sessions, is the space requirement for output only (so that pub/sub requirements) are sufficient. Or should this tradeoff be considered in the I2RS protocol requirements. Thank you for your help, Sue Hares ------=_NextPart_000_01C4_01D0550E.2275E840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS WG: =

 

We are trying to wrap of the protocol requirements for = I2RS within March.  This post ask 3 questions regarding the I2RS = requirements. 

 

Question = 1 context:  

The I2RS = architecture states in section 1.1 that the I2RS interface should be: = programmatic, asynchronous, and offers fast, interactive access for = atomic operations.  This posts asks if we need to require a = checkpoint to make asynchronous functions work.

 

In a review = by the security directorate, the reviewer asked:  “Is = security and the support for the asynchronous nature of the protocol = fully supported?”  In the reviewers mind Asynchronous usually = means the following:

 

1)      = The protocol can launch operations and then = check back later whether they successfully completed.

2)      =  If you want to execute a second operation = only if a first succeeds (or to guarantee the order in which they = execute), you need to at some point wait for operations to = complete.

3)      = There is also substantial overhead in supporting = asynchronous operation in that all transactions need labels so that they = can be queried?

 

Question = 1:  Do we believe that netconf or restconf augmented by the = traceability requirements and the pub/sub requirements provides this = support? 

Question 2: Do = we need a checkpoint (monotonically incrementing counter to accomplish = #2)?

 

 

Question 3 = Context:

The security directorate = reviewer of the I2RS architecture stated:

“ A conceptually simpler strategy [than the = asynchronous strategy] is to say that since a client can make multiple = parallel connections to an agent that in cases where a client wants = asynchronous operation he opens multiple connections and launches one = asynchronous operation on each. The cost is that is has lower = performance in cases where there are large numbers of parallel = operations tying up lots of connection state.”

 

In my = understanding RESTCONF provides one operations per session. =

 

Question 3: If the I2RS client requires a = tradeoff where that restricts the space requirements for parallel = sessions, is the space requirement for output only (so that pub/sub = requirements) are sufficient.  Or should this tradeoff be = considered in the I2RS protocol requirements.

 

Thank you = for your help,

 

Sue = Hares

 

------=_NextPart_000_01C4_01D0550E.2275E840-- From nobody Mon Mar 2 14:44:44 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 6555E1A8A76; Mon, 2 Mar 2015 14:44:43 -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 0YbYBcX4EJpa; Mon, 2 Mar 2015 14:44:42 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8821A8A61; Mon, 2 Mar 2015 14:44:42 -0800 (PST) Received: by pdno5 with SMTP id o5so43068277pdn.8; Mon, 02 Mar 2015 14:44:41 -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=IB0nVNvfGl+o9nBf5+wSRzgSqMx5jN1rVCUdtKgX0Vg=; b=gUPtRdlG2gd0YuQYfKGOuITswrJxRXoxKqt2snaH1dNh43a3NrXsagiZ7W2SS9Jh4r 73Y9A7qiCKqVfuQFlMxFnpiT0A4xMI9QnzasXU1j631cxd4HqqVKhTtkP+UIG/57q0k6 IerM3dLNnJX+8GHM1MjOgg2KJTdAJ+95lx0FH2DBHlx9AiGL/YhUzyiOyZaRVBI/bg2d snH26rHrCS5xOcrXMtT2fBAmFov4kOATJCj3GblLqeWDZCdMalmp1taCTPD5FNlUhA2k oKB0/+6/T0SN8HxA2+EjLi/aU/axldAP5LPwgiDPUv1tkzUfEfq/I8t/UBXyo26JSZCX M3Og== X-Received: by 10.68.197.33 with SMTP id ir1mr50300778pbc.151.1425336281527; Mon, 02 Mar 2015 14:44:41 -0800 (PST) Received: from spandex.local (209-112-222-96-rb1.sol.dsl.dynamic.acsalaska.net. [209.112.222.96]) by mx.google.com with ESMTPSA id hl2sm3163784pdb.43.2015.03.02.14.44.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Mar 2015 14:44:40 -0800 (PST) Message-ID: <54F4E7D7.1000603@gmail.com> Date: Mon, 02 Mar 2015 13:44:39 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Susan Hares , i2rs@ietf.org, secdir@ietf.org References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> In-Reply-To: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 02 Mar 2015 22:44:43 -0000 On 3/2/15 1:27 PM, Susan Hares wrote: > This posts asks if we need to require a > checkpoint to make asynchronous functions work. Hi, Sue: I don't really understand the question. If you're going to specify that there's going to be support for asynchronous event processing, you need a model for that. It can be polling-based, callback-based, interrupt-based, and so on, and what data structures you'll require will depend on the model you choose. That includes both for naming and for coordination/scheduling. I'm not sure exactly what you mean by "checkpoint" (semaphores? locks?) but it may actually be out of scope - an implementation question. At any rate the first place to start is with coming up with a concurrency (or asynchrony) model, and then proceeding from there. Melinda From nobody Mon Mar 2 15:00:39 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 917E31A8A79 for ; Mon, 2 Mar 2015 15:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 0qwP5yIP2z4B for ; Mon, 2 Mar 2015 15:00:37 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0E81A1BFA for ; Mon, 2 Mar 2015 15:00:37 -0800 (PST) Received: by igal13 with SMTP id l13so21808882iga.5 for ; Mon, 02 Mar 2015 15:00:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oclt9Ekdhy4eXk6QKoTT1FZCUrkmZJ8fegYN+bN350I=; b=SKWplI71zNJciyIZWBYGyTRli0pLVJ8QRst8U9kncIykIgVkOiU0amFBl+LrLvcIcN E9PFokxBMJT/QSIHrvcqxW+oKr21keKPxc80DG4BI99jQQ30IiTLJlkBvFHrqAdRqur2 dT0jXzEvyS0Hyfyhnx0Hz7vHm9v2u2HElW5hUWpzHhOGuPIk1JzY61VUx++w4HOZSr1v 9eIjPm6jg9/L2Gutc4KsQlHEyMwI7eq6Bkgf2agzPKWraXJe3sxml8NV/kd+U4IcoXTc B41BnruVKU+18FyRjZTQ5o7FmwFdsBVX8HAwsB8/effY780qch5KFNM8RW7A8aqRzaGZ Zb2g== X-Gm-Message-State: ALoCoQmgC5DANnBqCDfbuEgJ9fprsyKd3ExiufZvtNzG26jsZjBVe6FFk8zkHdZbF9Ij4jUVMZdV X-Received: by 10.107.128.69 with SMTP id b66mr40244864iod.30.1425337236728; Mon, 02 Mar 2015 15:00:36 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id t41sm8764577ioi.0.2015.03.02.15.00.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 15:00:36 -0800 (PST) Message-ID: <54F4EB93.1020907@andyet.net> Date: Mon, 02 Mar 2015 16:00:35 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Leif Johansson , draft-ietf-stox-groupchat.all@tools.ietf.org, "secdir@ietf.org" , IESG References: <54F4A8E3.1010802@sunet.se> In-Reply-To: <54F4A8E3.1010802@sunet.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-stox-groupchat-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, 02 Mar 2015 23:00:38 -0000 On 3/2/15 11:16 AM, Leif Johansson 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 imo as ready as it is likely to be from a security > perspective. The security considerations section does contain an > I-D reference (draft-ietf-simple-chat) which needs to be resolved > before publication though. Hi Leif, thanks for the review. BTW, draft-ietf-simple-chat has been blocked for a long time on draft-ietf-precis-nickname, which should soon enter IETF Last Call (following on the recent approval of draft-ietf-precis-framework). Peter From nobody Mon Mar 2 15:39: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 669C21A8AB7; Mon, 2 Mar 2015 15:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SakssEEHlmdz; Mon, 2 Mar 2015 15:38:56 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E20181A8AB2; Mon, 2 Mar 2015 15:38:55 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Charlie Kaufman'" , References: In-Reply-To: Date: Mon, 2 Mar 2015 18:38:49 -0500 Message-ID: <01fd01d05542$097e0280$1c7a0780$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01D05518.20AED850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEpOfrZTIkE5qJcJWMsTwMBawRKtp5ObSiA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-architecture-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, 02 Mar 2015 23:39:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01FE_01D05518.20AED850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Charlie: Thank you for your wonderful review. I have worked on getting more defined response for December 22nd through February28th. I have reached a point of diminishing returns on the work - with what you may consider substantially the same comments. Please review the comments below. After you see these comments, if you would suggest what sections I should still fix in the architecture draft. I only found one section I could provide good additional text (which I included below). Sue -----Original Message----- From: Charlie Kaufman [mailto:charliekaufman@outlook.com] Sent: Monday, December 22, 2014 3:05 AM To: secdir@ietf.org Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org; iesg@ietf.org Subject: Secdir review of draft-ietf-i2rs-architecture-07 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. As an "architecture" document, this document does not specify the details that would allow one to review whether the security mechanisms were adequate. The Security Considerations section correctly notes that there is a need to transport this protocol over something that provides mutual authentication, confidentiality, and integrity to the data. It also notes that there needs to be some authorization mechanism that configures which authenticated clients are allowed to make what requests. There is no discussion of where this authorization comes from, and in particular whether the authorization data can be viewed or manipulated using this protocol, though my sense reading the document is that authorization data would be configured and manipulated by some other mechanism (as would the manipulation of client and server credentials). So I think we need to wait for the successor document with more meat to judge. Sue's Response: You are correct, the I2RS architecture does not provide the necessary detail to clearly define a security protocol. I2RS is an architecture designed to re-use other protocols. After a great deal of discussion in a few interims, Please take a look at the text below as an addition to section 4. This I2RS architecture describes interfaces that clearly require serious consideration of security. As an architecture, I2RS has been designed to re-utilize existing protocols that carry network management information. Two of existing protocol which the I2RS WG has select to re-use are NETCONF [RFC6541] and RESTCONF [draft-ietf-netconf-restconf]. The I2RS protocol design process is to specify additional requirements for these existing protocols in order to support the I2RS architecture. After the existing protocol (E.g. NETCONF or RESTCONF), has been alter to fit the I2RS requirements, the I2RS protocol will be evaluated against the I2RS requirements. Due to the re-use strategy of the I2RS architecture, this security section describes the assumed security environment for I2RS with additional detail on: a) identity and authentication, b) authorization, and c) client redundancy. Each protocol proposed for inclusions as an I2RS protocol will need to be evaluated for the security constraints of the protocol. That said, I would ask the designers some leading questions of the form "Have you considered.". Some relate to security and some don't. I'm not the best person to judge the answers, but I'm hoping the questions will kick off some discussion within the working group. It's likely that some of these issues have already been adequately discussed, in which case feel free to ignore them. Sue's Response: I appreciate your careful thought on these questions. We have considered these questions. Item #1 This document goes out of its way *not* to specify any security mechanisms in order to provide flexibility to implementers. That makes sense for a requirements document, but I'm not sure it makes sense for an architecture document. You are clearly going to need some security mechanisms, and for clients and agents to interoperate, they need to be standardized. My guess is that you will end up using SSL with either client certificates or with some lesser client to agent authentication mechanism inside an SSL connection with only a server certificate. Sue's response: If you examine NETCONF running over SSH (RFC4272) or over TLS, or RESTCONF running over HTTP over TLS, I believe you will see the type of SSL with certificates. Item #2 The mechanism you choose will determine the formats of the identity information you get and use to do lookups in your authorization tables. But section 7.1 says the protocol may need to run over TCP, SCTP, DCCP, and possibly other link types. Do you envision different security mechanisms for the different protocols? Sue's item#2 response: Our first focus is the security sessions found in NETCONF (SSH/TLS), or RESTCONF. However, a vocal subset of the WG suggests there is a small subset of I2RS users that may have no security requirements because it is a "read-only" set of public data. The difficulty is while the proponents in the WG are vocal, they have not provided a description of the solution. This response was delayed for 3 months while I as the WG chair attempted to get a clean description of this "read-only" case. Therefore, the architecture has an open window for this "light" weight protocol to run over TCP, SCTP, or DCCP in case something clever gets developed. If another 18 months pass, we will revise the architecture to remove this section. Item #3: In the third paragraph of section 4 (and in some other places), you talk about the I2RS Client acting as a broker forwarding requests for some other entity, and forwarding some opaque identifier of that requesting entity to the I2RS Agent for logging. This presumes that the I2RS is configured with (or has access to) the authorization information that says which requestors are permitted to do which operations. Item #3 response Secondary identity is just opaque string which is passed without verification for purposes of trouble shooting and logging changes. The WG likes your description below, but decided to take this is as a second pass protocol change as it does not appear to be as simply as you suggest. We will include this extensions as a potential optional feature in our requirements document. Your text below: A useful extension to the protocol would be to be able to forward a requestor-identity string that the Agent not only logs but also checks for proper authorization before performing the requested operation. The Agent would need to verify that both the Client and the client asserted identity of the requestor be authorized to perform the operation. This relatively simple change to the Agent and the protocol might permit a considerably simpler client (if this brokered-request behavior is actually common). Item #4 Section 1.1 says I2RS is described as an asynchronous programmatic interface. Asynchronous usually means that you can launch operations and then check back later whether they successfully completed. If you want to execute a second operation only if a first succeeds (or to guarantee the order in which they execute), you need to at some point wait for operations to complete. There is also substantial overhead in supporting asynchronous operation in that all transactions need labels so that they can be queried? Have you done that? Item #4: We believe the asynchronous operation works without the transaction label. However, I have queried the WG regarding your question regarding the netconf/restconf protocols with the pub/sub requirement ( draft-voit-i2rs-pub-sub-requirements-00). Item #5 A conceptually simpler strategy is to say that since a client can make multiple parallel connections to an agent that in cases where a client wants asynchronous operation he opens multiple connections and launches one asynchronous operation on each. The cost is that is has lower performance in cases where there are large numbers of parallel operations tying up lots of connection state. Item #5 response: I2RS use of RESTCONF for I2RS actions provides this mechanism. Item #6 Ephemeral statea: Section 6.2: The restriction that this protocol injects only ephemeral state seems surprising, especially given that the circumstances under which the ephemeral state is lost are defined in terms of a network device reboot. Some network devices may not have a clear notion of a reboot, or might do it so rarely as to render such functionality useless. I was confused by the discussion of agent reboots vs. device reboots. The first paragraph seems to say that ephemeral state is lost when the device reboots, but 6.2.1 seems to imply that state is lost when the agent reboots. The sentence "Just as routing state will usually be removed shortly after the failure is detected." seems to imply that ephemeral state might be lost when a client reboots. Have you considered what happens to state when a client disappears but the agent and server stay around forever. There is an option later in the document for some sort of timeout, but I would think there would be some sort of mechanism to guarantee that all ephemeral state disappears eventually unless the requestor is still around implicitly renewing it. Item #6 Response: I worked through these use cases in January for netconf/restconf. I awaited the "read-only" proposal or a mini-proposal to see if there were any differences. We agree there are three types of loss: a) I2RS client - the loss of the I2RS client will be timed out on the I2RS agent. The recovery of data on the I2RS client is outside the scope of the I2RS protocol. b) Routing device crashes without losing the I2RS agent. This can be handled as an internal issue or a graceful termination. The I2RS agent has two potential situations: a) the I2RS agent can recover the all device state or b) the I2RS agent cannot recover all device state. If case A, then the reboot has been buffered by the High-Availability of the routing system. It is as though the reboot never happened. If case b, all ephemeral state must be flushed via a graceful termination. The graceful termination causes a disconnect, reboot, and restart. The I2RS agent needs to have a time-out period so the I2RS client knows when to consider the I2RS Agent as DOA after the reboot. c) I2rs Agent fails - and all ephemeral state is flushed because the I2RS fails. This recovery is an unexpected failure so the I2RS agent upon reboot must send the NOTIFICATION_I2RS_AGENT_STARTING to all cached nodes. These types of processes are fairly common in routing protocols. I would appreciate any comments on how I might clarify the text. Item #7: Also in 6.2.1, it appears that one piece of state is explicitly not ephemeral... the agent keeps a non-ephemeral list of clients to notify when ephemeral state is lost. If the client is not accessible, for how long does the agent continue to try to contact it? Forever? Item #7 Response: The I2RS agent has a time-out feature that indicates this point. See the above 3 cases. Item #8 pub/sub requirments: The protocol requires that agents be able to open connections to clients (in addition to clients being able to open connections to agents). This will introduce lots of challenges. It means the client needs an open port to accept connections, likely an SSL certificate, and will be in trouble if it is behind a NAT or is mobile and does not have a stable IP address. Other parts of the spec mention that two entities might have the same client identity. In such cases, it will be tricky for the agent to connect to "the right instance". It might be better to only allow clients to initiate connections to agents, possibly with some sort of unauthenticated notification from agent to client that initiating such a connection would be a good idea (to reduce the overhead of the polling that would otherwise be necessary). Item #8 response: Could you review the requirements described for publication/subscription feature described in: draft-voit-i2rs-pub-sub-requirements-00? The key requirement is the following: "Put simply, periodic fetching of data is not an adequate solution for applications requiring frequent or prompt updates of remote object state. Trying to impose a polling based solution to this problem imposes load on networks, devices, and applications. Additionally, polling solutions are brittle in the face of communication glitches, and they have limitations in their ability to synchronize and calibrate retrieval intervals across a network. I2RS WG documents have expressed a need for more robust YANG object subscriptions. Similar discussions are underway in NETMOD and NETCONF. With the support of standards bodies such as OMG (DDS) , XMPP.org standard, generic Pub/Sub mechanisms to communicate data updates have been defined and proven themselves in a wide variety of deployments" We thought this set of features matched the description in the architecture text. If not, could you give me some insight on where you see a disconnect. #item 9: My first question when I started reading this document was why do we need a new protocol. Wouldn't SNMP or NETCONF do this just fine? And there are probably lots of others. Section 3.1 says "There have been many efforts over the years to improve the access to the information available to the routing and forwarding system." It would be good to understand why those efforts failed before inventing some new syntax (when it is unlikely the syntax is what killed previous efforts). Then section 7.1 says the protocol will be "based on" NETCONF and RESTCONF. What does "based on" mean in this context? Item 9 response: SNMP MIB modules are problematic for routing. NETCONF and RESTCONF have been adopted by the working group as the initial protocols that the I2RS WG suggests are modified shortly. Based on means that "I2RS" does not find all of its features to exist inside of NETCONF or RESTCONF. However, NETCONF and RESTCONF provide 80% of the properties needed. The I2RS requirements are to specify these additional features. Item 10: Section 7.8 talks about "collisions", but it wasn't clear (at least to me) whether these were collisions in the time sense where two requests are made simultaneously by different clients vs. whether it is a case where once client tries to override the setting of another client. I also wonder whether there are cases where two changes would interact in some way other than one of them winning, as when two clients each want to increment the bandwidth of some virtual like over which they are both tunneling traffic (and where the correct result is to add the two increments). Item 10 response: The I2RS debated this issue at length. Please note the collisions occur only if two clients with the same priority seek to write something in the agent. In the overwrite case, if the client has a higher priority the overwrite is accepted. If the client has a lesser priority, the overwrite is denied. Only in the case where the priority is identical does the agent detection a collision. In the simultaneous write by two different clients or the over-write, the assumption is that the collision is an administrative error. If the two clients want to both increment bandwidth at the same priority Item 11: The last paragraph of 7.9 says "the protocol will include an explicit reply to modification or write operations even when they fully succeed". How does this relate to the asynchronous nature of the protocol? Item 11 response: If you use a netconf mechanism, you could use an RPC that would have a later acknowledgment. If you use a restconf mechanism, the restconf could contain a positive response per request. You can also use the RPC feature. Good luck with this! --Charlie ------=_NextPart_000_01FE_01D05518.20AED850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charlie:

 

Thank = you for your wonderful review.  I have worked on getting more = defined response for December 22nd through = February28th.  I have reached a point of diminishing = returns on the work – with what you may consider substantially the = same comments.

 

Please review the comments below.  After you = see these comments, if you would suggest what sections I should still = fix in the architecture draft.  I only found one section I could = provide good additional text (which I included below).

 

Sue =

 

-----Original Message-----

From: Charlie Kaufman [mailto:charliekaufman@outlook.= com]

Sent: Monday, December = 22, 2014 3:05 AM

To: secdir@ietf.org

Cc: draft-iet= f-i2rs-architecture.all@tools.ietf.org; iesg@ietf.org

Subject: Secdir review of = draft-ietf-i2rs-architecture-07

 

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.

 

As an = “architecture” document, this document does not specify the = details that would allow one to review whether the security mechanisms = were adequate. The Security Considerations section correctly notes that = there is a need to transport this protocol over something that provides = mutual authentication, confidentiality, and integrity to the data. It = also notes that there needs to be some authorization mechanism that = configures which authenticated clients are allowed to make what = requests. There is no discussion of where this authorization comes from, = and in particular whether the authorization data can be viewed or = manipulated using this protocol, though my sense reading the document is = that authorization data would be configured and manipulated by some = other mechanism (as would the manipulation of client and server = credentials). So I think we need to wait for the successor document with = more meat to judge.

 

Sue's = Response:

 

You are correct, the I2RS = architecture does not provide the necessary detail to clearly define a = security protocol.  I2RS is an architecture designed to re-use = other protocols.  After a great deal of discussion in a few = interims, Please take a look at the text below as an addition to section = 4.   

 

This I2RS architecture describes interfaces that = clearly require

serious = consideration of security. As an architecture, I2RS has

been designed to re-utilize existing protocols that = carry network

management = information. Two of existing protocol which the

I2RS WG has select to re-use are NETCONF [RFC6541] = and RESTCONF

[draft-ietf-netconf-restconf]. The I2RS protocol = design process

is to specify = additional requirements for these existing protocols

in order to support the I2RS architecture.  = After the existing protocol

(E.g. = NETCONF or RESTCONF), has been alter to fit the I2RS requirements, =

the I2RS protocol will be = evaluated against the I2RS requirements.

 

Due to = the re-use strategy of the I2RS architecture, this security section =

describes the assumed security = environment for I2RS with additional detail on:

a) identity and authentication, b) authorization, = and c) client redundancy.

Each = protocol proposed for inclusions as an I2RS protocol

will need to be evaluated for the security = constraints of the protocol. 

 

 

That = said, I would ask the designers some leading questions of the form = “Have you considered…”. Some relate to security and = some don’t. I’m not the best person to judge the answers, = but I’m hoping the questions will kick off some discussion within = the working group. It's likely that some of these issues have already = been adequately discussed, in which case feel free to ignore = them.

 

Sue’s Response: I = appreciate your careful thought on these questions.  We have = considered these questions.

 

Item #1 =

This document goes out = of its way *not* to specify any security mechanisms in order to provide = flexibility to implementers. That makes sense for a requirements = document, but I'm not sure it makes sense for an architecture document. = You are clearly going to need some security mechanisms, and for clients = and agents to interoperate, they need to be standardized. My guess is = that you will end up using SSL with either client certificates or with = some lesser client to agent authentication mechanism inside an SSL = connection with only a server certificate.

 

Sue’s response:  If you examine NETCONF = running over SSH (RFC4272) or over TLS, or RESTCONF running over HTTP = over TLS, I believe you will see the type of SSL with certificates. =

  

Item #2 =

The mechanism you = choose will determine the formats of the identity information you get = and use to do lookups in your authorization tables. But section 7.1 says = the protocol may need to run over TCP, SCTP, DCCP, and possibly other = link types. Do you envision different security mechanisms for the = different protocols?

 

Sue’s item#2 response:  Our first focus = is the security sessions found in NETCONF (SSH/TLS), or = RESTCONF.   However, a vocal subset of the WG suggests there = is a small subset of I2RS users that may have no security requirements = because it is a “read-only” set of public data.  The = difficulty is while the proponents in the WG are vocal, they have not = provided a description of the solution.  This response was delayed = for 3 months while I as the WG chair attempted to get a clean =  description of this “read-only” case.  Therefore, = the architecture has an open window for this “light” weight = protocol to run over TCP, SCTP, or DCCP in case something clever gets = developed.   

If another 18 months = pass, we will revise the architecture to remove this section. =

 

Item #3: =

In the third paragraph of = section 4 (and in some other places), you talk about the I2RS Client = acting as a broker forwarding requests for some other entity, and = forwarding some opaque identifier of that requesting entity to the I2RS = Agent for logging. This presumes that the I2RS is configured with (or = has access to) the authorization information that says which requestors = are permitted to do which operations.

 

Item #3 response

Secondary identity is = just opaque string which is passed without verification for purposes of = trouble shooting and logging changes.  The WG likes your = description below, but decided to take this is as a second pass protocol = change as it does not appear to be as simply as you suggest.  We = will include this extensions as a potential optional feature in our = requirements document.

 

Your = text below:

A useful extension to the protocol would be to = be able to forward a requestor-identity string that the Agent not only = logs but also checks for proper authorization before performing the = requested operation. The Agent would need to verify that both the Client = and the client asserted identity of the requestor be authorized to = perform the operation. This relatively simple change to the Agent and = the protocol might permit a considerably simpler client (if this = brokered-request behavior is actually = common).

 

 

Item #4  

Section 1.1 says I2RS is described as an = asynchronous programmatic interface. Asynchronous usually means that you = can launch operations and then check back later whether they = successfully completed. If you want to execute a second operation only = if a first succeeds (or to guarantee the order in which they execute), = you need to at some point wait for operations to complete. There is also = substantial overhead in supporting asynchronous operation in that all = transactions need labels so that they can be queried? Have you done = that?

 

Item #4: We believe the = asynchronous operation works without the transaction label. However, I = have queried the WG regarding your question regarding the = netconf/restconf protocols with the pub/sub requirement (draft-voit-i2rs-pub-sub-requirements-00). =

 

 

Item #5 =

A conceptually simpler = strategy is to say that since a client can make multiple parallel = connections to an agent that in cases where a client wants asynchronous = operation he opens multiple connections and launches one asynchronous = operation on each. The cost is that is has lower performance in cases = where there are large numbers of parallel operations tying up lots of = connection state.

Item #5 response: =   

I2RS use of RESTCONF for I2RS actions provides this = mechanism.

 

 

Item #6 Ephemeral statea:

Section 6.2: The restriction that this protocol = injects only ephemeral state seems surprising, especially given that the = circumstances under which the ephemeral state is lost are defined in = terms of a network device reboot.

 

Some = network devices may not have a clear notion of a reboot, or might do it = so rarely as to render such functionality useless. I was confused by the = discussion of agent reboots vs. device reboots. The first paragraph = seems to say that ephemeral state is lost when the device reboots, but = 6.2.1 seems to imply that state is lost when the agent reboots. The = sentence “Just as routing state will usually be removed shortly = after the failure is detected…” seems to imply that = ephemeral state might be lost when a client reboots. Have you considered = what happens to state when a client disappears but the agent and server = stay around forever. There is an option later in the document for some = sort of timeout, but I would think there would be some sort of mechanism = to guarantee that all ephemeral state disappears eventually unless the = requestor is still around implicitly renewing it.

 

Item #6 Response:

I worked through these = use cases in January for netconf/restconf.  I awaited the = “read-only” proposal or a mini-proposal to see if there were = any differences.

 

We agree there are three = types of loss:

a)      = I2RS client = – the loss of the I2RS client will be timed out on the I2RS agent. =  The recovery of data on the I2RS client is outside the scope of = the I2RS protocol.

 

b)      = Routing device = crashes without losing the I2RS agent.  This can be handled as an = internal issue or a graceful termination.

 

The I2RS agent has = two potential situations: a) the I2RS agent can recover the all device = state or b) the I2RS agent cannot recover all device state.  If = case A, then the reboot has been buffered by the High-Availability of = the routing system.  It is as though the reboot never = happened.  If case b, all ephemeral state must be flushed via a = graceful termination.   The graceful termination causes a = disconnect, reboot, and restart.  The I2RS agent needs to have a = time-out period so the I2RS client knows when to consider the I2RS Agent = as DOA after the reboot.

 

c)       = I2rs Agent = fails – and all ephemeral state is flushed because the I2RS = fails.  This recovery is an unexpected failure so the I2RS agent = upon reboot must send the NOTIFICATION_I2RS_AGENT_STARTING to all cached = nodes.

 

These types of processes = are fairly common in routing protocols.  I would appreciate any = comments on how I might clarify the text.

 

Item #7:

Also in 6.2.1, it appears that one piece of state = is explicitly not ephemeral... the agent keeps a non-ephemeral list of = clients to notify when ephemeral state is lost. If the client is not = accessible, for how long does the agent continue to try to contact it? = Forever?

 

Item #7 Response:  = The I2RS agent has a time-out feature that indicates this point. =  See the above 3 cases.

 

Item #8 pub/sub requirments: =

The protocol requires that = agents be able to open connections to clients (in addition to clients = being able to open connections to agents). This will introduce lots of = challenges. It means the client needs an open port to accept = connections, likely an SSL certificate, and will be in trouble if it is = behind a NAT or is mobile and does not have a stable IP address. Other = parts of the spec mention that two entities might have the same client = identity. In such cases, it will be tricky for the agent to connect to = "the right instance". It might be better to only allow clients = to initiate connections to agents, possibly with some sort of = unauthenticated notification from agent to client that initiating such a = connection would be a good idea (to reduce the overhead of the polling = that would otherwise be necessary).

 

Item #8 response:

Could you review the = requirements described for publication/subscription feature described = in:

draft-voit-i2rs-pub-sub-requirements-00? =  

 

The key requirement is the following: =

 

   “Put simply, periodic fetching = of data is not an adequate solution for

   applications requiring frequent or = prompt updates of remote object

   state.  Trying to impose a = polling based solution to this problem

   imposes load on networks, devices, and = applications.  Additionally,

   polling solutions are brittle in the = face of communication glitches,

   and they have limitations in their = ability to synchronize and

   calibrate retrieval intervals across a = network.

 

  I2RS WG documents have expressed a need for = more robust YANG object

   subscriptions.  Similar = discussions are underway in NETMOD and

   NETCONF.  With the support of = standards bodies such as OMG (DDS) ,

   XMPP.org standard, generic Pub/Sub = mechanisms to communicate data

   updates have been defined and proven = themselves in a wide variety of

   deployments”

 

We thought this set of features matched the = description in the architecture text.  If not, could you give me = some insight on where you see a disconnect.

 

#item 9:

My first question when I started reading this = document was why do we need a new protocol. Wouldn't SNMP or NETCONF do = this just fine? And there are probably lots of others. Section 3.1 says = "There have been many efforts over the years to improve the access = to the information available to the routing and forwarding system." = It would be good to understand why those efforts failed before inventing = some new syntax (when it is unlikely the syntax is what killed previous = efforts). Then section 7.1 says the protocol will be "based = on" NETCONF and RESTCONF. What does "based on" mean in = this context?

 

Item 9 response: SNMP MIB modules are = problematic for routing.  NETCONF and RESTCONF have been adopted by = the working group as the initial protocols that the I2RS WG suggests are = modified shortly.

Based on means = that “I2RS” does not find all of its features to exist = inside of NETCONF or RESTCONF. However, NETCONF and RESTCONF provide 80% = of the properties needed.  The I2RS requirements are to specify = these additional features.

 

Item 10:  

Section 7.8 talks about "collisions", but = it wasn't clear (at least to me) whether these were collisions in the = time sense where two requests are made simultaneously by different = clients vs. whether it is a case where once client tries to override the = setting of another client. I also wonder whether there are cases where = two changes would interact in some way other than one of them winning, = as when two clients each want to increment the bandwidth of some virtual = like over which they are both tunneling traffic (and where the correct = result is to add the two increments).

 

Item 10 response:

The I2RS debated this = issue at length.  Please note the collisions occur only if two = clients with the same priority seek to write something in the agent. =  In the overwrite case, if the client has a higher priority the = overwrite is accepted.  If the client has a lesser priority, the = overwrite is denied.  Only in the case where the priority is = identical does the agent detection a collision.  In the = simultaneous write by two different clients or the over-write, the = assumption is that the collision is an administrative error.  If = the two clients want to both increment bandwidth at the same priority =

 

Item 11: =  

The last paragraph = of 7.9 says "the protocol will include an explicit reply to = modification or write operations even when they fully succeed". How = does this relate to the asynchronous nature of the = protocol?

Item 11 response:

If you use a netconf mechanism, you could use an = RPC that would have a later acknowledgment.

If you use a restconf mechanism, the restconf could = contain a positive response per request.  You can also use the RPC = feature.

 

 

Good = luck with this!

 

        &nbs= p;       = --Charlie

------=_NextPart_000_01FE_01D05518.20AED850-- From nobody Mon Mar 2 19:55: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 596991A0242 for ; Mon, 2 Mar 2015 19:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXFH_iz7q8XK for ; Mon, 2 Mar 2015 19:54:56 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7AC1A0130 for ; Mon, 2 Mar 2015 19:54:56 -0800 (PST) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t233stNh012916; Mon, 2 Mar 2015 22:54:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1425354895; bh=XL1X54DxLo1vaAhiz2OE5bhiweduj/C/+mIXinXcu4c=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=UIKy4k/SZQZRvm2ZOG/9CKcWaDYSQZyzmiSIj9LTLWLFNy8hERNMxKOcNjjsQFV9E u+y+5DrTIRq+KjlgBQ/TCKZCHLOk/Gh3k6DgnbAtq/v4NyI/dByCM5JUGsCzR2DXIY lkjAHmqiCChD5e+dlYDqkxHZuIS75JhWxC2WYB9g= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t233spS6002574; Mon, 2 Mar 2015 22:54:51 -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; Mon, 2 Mar 2015 22:54:51 -0500 From: Chris Inacio To: "secdir-secretary@mit.edu" Thread-Topic: [secdir] Assignments Thread-Index: AQHQVPjmBlJCfLtQjkqJ/w4r9HgtLp0KdXmA Date: Tue, 3 Mar 2015 03:54:51 +0000 Message-ID: <310E5277-9CA0-4130-BE3B-FD9CC20F7ABD@cert.org> References: <21748.31172.981305.579910@fireball.kivinen.iki.fi> In-Reply-To: <21748.31172.981305.579910@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.97.106] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] Assignments 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, 03 Mar 2015 03:54:58 -0000 S2F0aGxlZW4sIFN0ZXBoZW4sDQoNCkp1c3QgYSBoZWFkcyB1cCB0aGF0IEkgd2lsbCB0cnksIGJ1 dCBhIDEyMCBwYWdlIGRyYWZ0IG9uIGEgcHJvdG9jb2wgSeKAmW0gbm90IGZhbWlsaWFyIHdpdGgg eWV0IHdpbGwgYmUgYSBjaGFsbGVuZ2UgdG8gZ2V0IGZ1bGx5IHJldmlld2VkIGluIDEwIGRheXMu DQoNCi0tDQpDaHJpcyBJbmFjaW8NCmluYWNpb0BjZXJ0Lm9yZw0KDQoNCg0KPiBPbiBNYXIgMiwg MjAxNSwgYXQgOTo1NSBBTSwgVGVybyBLaXZpbmVuIDxraXZpbmVuQGlraS5maT4gd3JvdGU6DQo+ IA0KPiBCZWNhdXNlIG9mIG15IHZhY2F0aW9uIEkgd2FzIG5vdCBhYmxlIHRvIGRvIGFzc2lnbm1l bnRzIGZvciBsYXN0IGZldw0KPiB3ZWVrcywgc28gc29tZSBvZiB0aGVzZSByZXZpZXdzIGhhdmUg VkVSWSBzaG9ydCB0aW1lIHRvIGJlIGNvbXBsZXRlZC4NCj4gSSBob3BlIHBlb3BsZSBhcmUgc3Rp bGwgYWJsZSB0byBkbyB0aGUgcmV2aWV3cyBldmVuIHdoZW4gdGhlIHRlbGVjaGF0DQo+IGlzIGFs cmVhZHkgaW4gdGhpcyB3ZWVrLg0KPiANCj4gUmV2aWV3IGluc3RydWN0aW9ucyBhbmQgcmVsYXRl ZCByZXNvdXJjZXMgYXJlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJh Yy93aWtpL1NlY0RpclJldmlldw0KPiANCj4gU2ltb24gSm9zZWZzc29uIGlzIG5leHQgaW4gdGhl IHJvdGF0aW9uLg0KPiANCj4gRm9yIHRlbGVjaGF0IDIwMTUtMDMtMDUNCj4gDQo+IEFsYW4gRGVL b2sgICAgICAgICAgICAgVCAyMDE1LTAyLTE4IGRyYWZ0LWlldGYtdGVhcy1yc3ZwLXRlLWxpLWxi LTA0DQo+IERvbmFsZCBFYXN0bGFrZSAgICAgICAgVCAyMDE1LTAyLTIwIGRyYWZ0LWlldGYtNnRp c2NoLXRzY2gtMDUNCj4gT2xhZnVyIEd1ZG11bmRzc29uICAgICBUIDIwMTUtMDMtMDUgZHJhZnQt aWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMtMTMNCj4gUGhpbGxpcCBIYWxsYW0tQmFrZXIgICBUIDIw MTUtMDMtMDMgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYt dGUtMDkNCj4gU3RldmUgSGFubmEgICAgICAgICAgICBUIDIwMTUtMDMtMDMgZHJhZnQtaWV0Zi1z dG94LWNoYXQtMTANCj4gRGF2aWQgSGFycmluZ3RvbiAgICAgICBUIDIwMTUtMDMtMDMgZHJhZnQt aWV0Zi1tcGxzLWxzcC1waW5nLXJlZ2lzdHJ5LTAyDQo+IEplZmZyZXkgSHV0emVsbWFuICAgICAg VCAyMDE1LTAzLTAzIGRyYWZ0LWlldGYtc3RveC1pbS0xMg0KPiBMZWlmIEpvaGFuc3NvbiAgICAg ICAgIFQgMjAxNS0wMy0wMyBkcmFmdC1pZXRmLXN0b3gtZ3JvdXBjaGF0LTEwDQo+IENhcmwgV2Fs bGFjZSAgICAgICAgICAgVCAyMDE1LTAyLTEwIGRyYWZ0LWlldGYtbmV0ZXh0LWFuaS1sb2NhdGlv bi0wOA0KPiANCj4gDQo+IEZvciB0ZWxlY2hhdCAyMDE1LTAzLTEyDQo+IA0KPiBEYXZlIENyaWRs YW5kICAgICAgICAgIFQgMjAxNS0wMi0xOCBkcmFmdC1pZXRmLXRlYXMtbHNwLWF0dHJpYnV0ZS1y by0wMw0KPiBEYW4gSGFya2lucyAgICAgICAgICAgIFQgMjAxNS0wMy0wNCBkcmFmdC1pZXRmLWRo Yy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTExDQo+IFBhdWwgSG9mZm1hbiAgICAgICAgICAgVCAy MDE1LTAzLTEyIGRyYWZ0LWlldGYtaWRyLWVycm9yLWhhbmRsaW5nLTE4DQo+IENocmlzIEluYWNp byAgICAgICAgICAgVCAyMDE1LTAzLTEwIGRyYWZ0LWlldGYtcGltLXJmYzQ2MDFiaXMtMDQNCj4g TWVsaW5kYSBTaG9yZSAgICAgICAgICBUIDIwMTUtMDItMjQgZHJhZnQtZmFsdHN0cm9tLXVyaS0x MQ0KPiANCj4gTGFzdCBjYWxscyBhbmQgc3BlY2lhbCByZXF1ZXN0czoNCj4gDQo+IERvcm90aHkg R2VsbGVydCAgICAgICAgICAyMDE1LTAyLTIzIGRyYWZ0LWlldGYtdGVhcy1tcGxzLXRwLXJzdnB0 ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDYNCj4gVG9iaWFzIEdvbmRyb20gICAgICAgICAgIDIwMTUt MDMtMTIgZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLTA0DQo+IERhbiBIYXJraW5z ICAgICAgICAgICAgICAyMDE0LTA2LTEzIGRyYWZ0LWlldGYtbW11c2ljLXJ0c3AtbmF0LWV2YWx1 YXRpb24tMTQNCj4gU2FtIEhhcnRtYW4gICAgICAgICAgICAgIDIwMTUtMDMtMTEgZHJhZnQtaWV0 Zi1uZXRjb25mLXJmYzU1MzliaXMtMDkNCj4gSmVmZnJleSBIdXR6ZWxtYW4gICAgICAgIDIwMTUt MDEtMDcgZHJhZnQtaWV0Zi1kbnNzZC1yZXF1aXJlbWVudHMtMDQNCj4gUmFkaWEgUGVybG1hbiAg ICAgICAgICAgUjIwMTUtMDMtMDkgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0xMQ0KPiBaYWNo IFNoZWxieSAgICAgICAgICAgICAgMjAxNC0wNi0wNiBkcmFmdC1ob3VzbGV5LWltcGxlbWVudGVy LW9ibGlnYXRpb25zLTAyDQo+IFNhbSBXZWlsZXIgICAgICAgICAgICAgICAyMDE1LTAyLTE2IGRy YWZ0LWlldGYtNm1hbi1yZXNpbGllbnQtcnMtMDQNCj4gLS0gDQo+IGtpdmluZW5AaWtpLmZpDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz ZWNkaXIgbWFpbGluZyBsaXN0DQo+IHNlY2RpckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcg0KPiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldw0KDQo= From nobody Tue Mar 3 00:45:56 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 E79691A1A77; Tue, 3 Mar 2015 00:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-JjVAr99anh; Tue, 3 Mar 2015 00:45:52 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298661A1A70; Tue, 3 Mar 2015 00:45:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0DAD31C0AD0; Tue, 3 Mar 2015 00:45:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (wlan.dagstuhl.de [192.76.146.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D7B161C029E; Tue, 3 Mar 2015 00:45:50 -0800 (PST) Message-ID: <54F574BD.5060403@joelhalpern.com> Date: Tue, 03 Mar 2015 03:45:49 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Susan Hares , i2rs@ietf.org References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> In-Reply-To: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Jeffrey Haas' , secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 03 Mar 2015 08:45:54 -0000 As written, it is hard to answer the questions. Particularly since RestConf is still under development, I expect that most of the requirements can be met. But I do not have enough information to know whether they are met. Further, the questions seem to assume specific means of meeting the requirement. They may well be the best means, but it is not obvious. Further comments in-line. Yours, Joel On 3/2/15 5:27 PM, Susan Hares wrote: > I2RS WG: > > We are trying to wrap of the protocol requirements for I2RS within > March. This post ask 3 questions regarding the I2RS requirements. > > *Question 1 context: * > > The I2RS architecture states in section 1.1 that the I2RS interface > should be: programmatic, asynchronous, and offers fast, interactive > access for atomic operations. This posts asks if we need to require a > checkpoint to make asynchronous functions work. > > In a review by the security directorate, the reviewer asked: “Is > security and the support for the asynchronous nature of the protocol > fully supported?” In the reviewers mind Asynchronous usually means the > following: > > 1)The protocol can launch operations and then check back later whether > they successfully completed. > > 2) If you want to execute a second operation only if a first succeeds > (or to guarantee the order in which they execute), you need to at some > point wait for operations to complete. > > 3)There is also substantial overhead in supporting asynchronous > operation in that all transactions need labels so that they can be queried? > > *Question 1:* Do we believe that netconf or restconf augmented by the > traceability requirements and the pub/sub requirements provides this > support? Drawing on the traceability requirement here assumes that the traceability reporting is to be within I@RS. This was not obvious. Inf act, if one is trying to diagnose problems / corruption of I2RS activity, one might well want traceability via means other than I2RS. It is clear that one can create an information model with access contro recording the results of operations, and allowing a reader to determine what has happened. It is not at all clear that pub/sub is needed to meet these requirements, although one could subscribe to such a table to get notifications of success / failure, which is not one of the listed requirements, but is clearly nice to have. Statement 3 asserts taht there is substantial overhead associated with this. While I would have to agree that there is overhead, I have trouble seeing it as "substantial". > > *Question 2:* Do we need a checkpoint (monotonically incrementing > counter to accomplish #2)? I can imagine multiple techniques to achieve goal #2. A monotonically increasing counter, across multiple clients, seems like one of the harder answers to actual use, although it would seem to work. > > Question 3 Context: > > The security directorate reviewer of the I2RS architecture stated: > > “ A conceptually simpler strategy [than the asynchronous strategy] is to > say that since a client can make multiple parallel connections to an > agent that in cases where a client wants asynchronous operation he opens > multiple connections and launches one asynchronous operation on each. > The cost is that is has lower performance in cases where there are large > numbers of parallel operations tying up lots of connection state.” > > In my understanding RESTCONF provides one operations per session. > > *Question 3:* If the I2RS client requires a tradeoff where that > restricts the space requirements for parallel sessions, is the space > requirement for output only (so that pub/sub requirements) are > sufficient. Or should this tradeoff be considered in the I2RS protocol > requirements. I am unable to parse the question. Is the question "should we allow multiple parallel sessions, but restrict the number of such sessions?" Or is the question whether we want to require parallel sessions to be used for asynchronous operations? The driver I understood for this requirement was that some operations may take time, and / or may produce significant volumes of response. > > Thank you for your help, > > Sue Hares > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Mar 3 06:28: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 B4E061A8740 for ; Tue, 3 Mar 2015 06:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 VE-XMTInzpZ9 for ; Tue, 3 Mar 2015 06:28:42 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C211A8742 for ; Tue, 3 Mar 2015 06:28:42 -0800 (PST) Received: by lbiv13 with SMTP id v13so18802799lbi.1 for ; Tue, 03 Mar 2015 06:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Loh3DMQyjEPRAvv3JxGmGY+fNYbXTsnjN9XtBuM1S8A=; b=MAe5eW+cowbFYXg4idUPpJ/bU6fjNNV/lbJCPA0n16zlgOGqQmu2jM7Ml1sSHpWOXa meyUlimukSghy71ii6rhBpqPjH1fn+wOPHsCBwD12KHIJUrKS8bHJcr35yzCmqBkOWND tGdKOe9Vi6VwgQF36X2G/PIf2sRdzN1pkH2yeR58N24A5OVtd2fqbgEPlTzKuLQyKuNv AarbJhP+epOT/MALOyefBxa2rRkOJRs79zZnNJBDOateUZRDgHhy+VmsMbVcSOcu9SRl sI8CA7kUP7gOlTR7esIPwSJiHbHyMPJ7IYiEoabUwBrvhdLtYO4xmmXbJkwrCbvLs3VE BwIA== MIME-Version: 1.0 X-Received: by 10.152.120.8 with SMTP id ky8mr28056670lab.118.1425392920893; Tue, 03 Mar 2015 06:28:40 -0800 (PST) Sender: hallam@gmail.com Received: by 10.113.3.165 with HTTP; Tue, 3 Mar 2015 06:28:40 -0800 (PST) Date: Tue, 3 Mar 2015 09:28:40 -0500 X-Google-Sender-Auth: 3aaDQO35WxyMIzDTPyFreqXL-UA Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" , draft-ietf-ccamp-gmpls-general-constraints-ospf-te-all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0122aef8b71e440510632685 Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-ccamp-gmpls-general-constraints-ospf-te-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: Tue, 03 Mar 2015 14:28:43 -0000 --089e0122aef8b71e440510632685 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. Given the short time available for the review, I have only been able to skim the material. Since this protocol is happening at the link layer, the range of security considerations that are in scope is fairly small. While confidentiality of the data plane is not at issue here, the control plane probably contains much information that is commercially sensitive. --089e0122aef8b71e440510632685 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.


Given the short time available for the review, I have only been able to s= kim the material.

Since this protocol is happening= at the link layer, the range of security considerations that are in scope = is fairly small.=C2=A0

While confidentiality of th= e data plane is not at issue here, the control plane probably contains much= information that is commercially sensitive.=C2=A0
--089e0122aef8b71e440510632685-- From nobody Tue Mar 3 14:08: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 24E0A1ACDDE; Tue, 3 Mar 2015 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.156 X-Spam-Level: X-Spam-Status: No, score=-97.156 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slViJgN8oVBp; Tue, 3 Mar 2015 14:08:10 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A172F1ACDE0; Tue, 3 Mar 2015 14:08:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Melinda Shore'" , , References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> In-Reply-To: <54F4E7D7.1000603@gmail.com> Date: Tue, 3 Mar 2015 17:08:05 -0500 Message-ID: <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKNoMDmLw8r4tCY9pMrxOLsQQAbewIgtX/Tm3+rlYA= X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 03 Mar 2015 22:08:11 -0000 Melinda: Thank you for your clear question - let me try to unpack and answer your question. I really appreciate your aid in working through these cases. The asynchronous models we've discussed are: 1) polling based - I2RS client queries at a set of agents to receive status information 2) call-back based - the I2RS Client performs an action (adds an interface) and the I2RS agent returns a response after the sequence is done. 3) pub/sub based - meaning the I2RS clients sign up to receive publications of results. 4) atomic based - a sequence of commands that are done and then returned with a call-back. (if you think I've missed one, please let me know). IHMO the use of a checkpoint in each of the cases is the following. 1) polling The checkpoint (or revision counter) would be used to indicate if something else had written or change the portion of the tree after the polling began. This checkpoint can be for the whole tree or a model. The keeping of a checkpoint per item within a model may be prohibited. 2) call-back item If another higher priority interrupt, interrupts the write with call-back response - then an error message would indicated the interrupt. If a lower priority commands tries to interrupt, the architecture indicates the lower priority command will receive an error in the call-back. If a same priority command tries to interrupt the command, it is an error and both commands should be flagged. In my understanding, the checking point is not of a use in this case. 3) pub/sub item A checkpoint may provide an indication if something changes between subsequent updates from a pub/sub. This information may be sent in the pub/sub message sequences. 4) atomic groupings of commands that return with a command. The atomic groupings of a commands either succeeds or fails based on same circumstances as the call-back. A checkpoint really doesn't aid the result here. My understanding on the support of each of these four functions in RESTCONF/NETCONF depends on Ephemeral data store issues. Without a NETCONF solution to the ephemeral datastore, only restconf can share definitions and data between I2RS agent models and netconf data models. IMHO this sharing makes data-model creation a lot easier. Therefore, let me comment on the RESTCONF support for the four functions: 1) polling - RESTCONF GET/QUERY can poll for data I2RS data (no ephemeral data store issues) 2) call/back item: RESTCONF RPC mechanism seem to be supported as well as the POST, PUT, PATCH, and DELETE. 3) pub/sub: call-home features exist and a pub/sub feature solution has been proposed. 4) atomic group: RESTCONF provides the automatic RESTCONF provides integrity and confidentiality of the data and mutually authenticated client-server identities. Sue Hares -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com] Sent: Monday, March 02, 2015 5:45 PM To: Susan Hares; i2rs@ietf.org; secdir@ietf.org Subject: Re: [secdir] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF On 3/2/15 1:27 PM, Susan Hares wrote: > This posts asks if we need to require a checkpoint to make > asynchronous functions work. Hi, Sue: I don't really understand the question. If you're going to specify that there's going to be support for asynchronous event processing, you need a model for that. It can be polling-based, callback-based, interrupt-based, and so on, and what data structures you'll require will depend on the model you choose. That includes both for naming and for coordination/scheduling. I'm not sure exactly what you mean by "checkpoint" (semaphores? locks?) but it may actually be out of scope - an implementation question. At any rate the first place to start is with coming up with a concurrency (or asynchrony) model, and then proceeding from there. Melinda From nobody Wed Mar 4 02:24: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 453171A1A9D; Wed, 4 Mar 2015 02:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, 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 i35-3Nk4P-Ck; Wed, 4 Mar 2015 02:24:48 -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 C669D1A1A9B; Wed, 4 Mar 2015 02:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12206; q=dns/txt; s=iport; t=1425464688; x=1426674288; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DTslvTs3oReJoUZ/EODtVg2lAmuD87TuuxWIU6wZTXI=; b=InTdfle+DAgXkidpDlL6dbrQe8Gmw+ikBB8yoM2DiBhz+sglUoPDIJsP iSvf3y/uZNrYV5YYjmke7+8AutW5lMtebAaLxCuOKatwZOKOb9gLuwNdF G5i36cVkK6CtXwg4tKjNmlHejpaQcMlEHnPC7ejvTmqoK41aq9gN80nf1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKCQA03PZU/5NdJa1RCYMCUk4MBIMHu12IIgIcgQdNAQEBAQEBfIQPAQEBAwEjBA0+BwULAgEGAhgCAiYCAgIwFRACBA4FiCcIn3ucbJoqAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXGEEygzB4JoL4EUAQSOAIF/hXuDUYEagyWCU4kWg0AjggEBHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,686,1418083200"; d="scan'208";a="128714029" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 04 Mar 2015 10:24:47 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t24AOkfN020389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 10:24:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 04:24:46 -0600 From: "Francois Le Faucheur (flefauch)" To: "Klaas Wierenga (kwiereng)" Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQVmVv5C9SG+zPj0yqYbUG8Io8tg== Date: Wed, 4 Mar 2015 10:24:45 +0000 Message-ID: <57CC830A-5092-4BA3-9628-90B148951A16@cisco.com> References: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> In-Reply-To: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.202] Content-Type: text/plain; charset="utf-8" Content-ID: <023B233F5B82B241BE6B7C5EB45E55BC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-logging.all@tools.ietf.org" , "Francois Le Faucheur \(flefauch\)" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 10:24:50 -0000 SGVsbG8gS2xhYXMsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFByb3Bvc2VkIHJlc29sdXRp b24gb2YgY29tbWVudHMgYmVsb3c6DQoNCj4gT24gMTMgRmViIDIwMTUsIGF0IDE3OjA1LCBLbGFh cyBXaWVyZW5nYSAoa3dpZXJlbmcpIDxrd2llcmVuZ0BjaXNjby5jb20+IHdyb3RlOg0KPiANCj4g SGksDQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlICBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg dGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ IA0KPiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgbG9nZ2luZyBmb3JtYXQgYW5kIHRoZSBl eGNoYW5nZSBwcm90b2NvbCBmb3IgbG9nZ2luZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIHVwc3RyZWFt IGFuZCBkb3duc3RyZWFtIENETnMgdGhhdCBhcmUgaW50ZXJjb25uZWN0ZWQgdXNpbmcgdGhlIENE TiBpbnRlcmNvbm5lY3Rpb24gZnJhbWV3b3JrLg0KPiANCj4gVGhlIGRvY3VtZW50IGlzIHdlbGwg d3JpdHRlbiBhbmQgZWFzeSB0byByZWFkLiBJIGhhdmUgZmV3IGlzc3VlcyB3aXRoIHRoZSBtYWlu IHRleHQsIGJ1dCBkbyBoYXZlIHNvbWUgY29uY2VybnMgYWJvdXQgdGhlIHNlY3VyaXR5IGFuZCBw cml2YWN5IGNvbnNpZGVyYXRpb25zLiBJIHRoZXJlZm9yZSBjb25zaWRlciB0aGUgZG9jdW1lbnQg 4oCccmVhZHkgd2l0aCBpc3N1ZXPigJ0NCj4gDQo+IERldGFpbGVkIGNvbW1lbnRzOg0KPiANCj4g KiBJbnRyb2R1Y3Rpb24gYW5kIEZpZ3VyZSAxOiBXaGF0IGlzIG5vdCBjbGVhciB0byBtZSBmcm9t IHRoZSB0ZXh0IGlzIHdoZXRoZXIgdGhlcmUgaXMgYW55IGZ1bmN0aW9uYWwgZGlmZmVyZW5jZSBi ZXR3ZWVuIGFuIHVDRE4gYW5kIGFuIGRDRE4sb3IgdGhhdCB0aGV5IGp1c3QgaGFwcGVuIHRvIGJl IGluIGEgaGllcmFyY2hpY2FsIHJlbGF0aW9uIHRvIGVhY2ggb3RoZXIuICBJIGNvdWxkIGFsc28g ZmluZCBubyByZWZlcmVuY2UgdG8gdGhhdCBpbiBSRkM3MzM2LiBUaGUgZmFjdCB0aGF0IGluIEZp Z3VyZSAxIGRDRE4tMiBpcyBub3QgYWxzbyBsYWJlbGVkIGFzIHVDRE4tMiBsZWQgbWUgdG8gYmVs aWV2ZSB0aGF0IHRoZXJlIGlzIGEgZnVuY3Rpb25hbCBkaWZmZXJlbmNlLiBIb3dldmVyIGZyb20g dGhlIHRleHQgaXQgYXBwZWFycyB0aGF0IGFueSB0d28gRENOcyBjYW4gYmUgaW4gYW4gdS1kIHJl bGF0aW9uIHRvIGVhY2ggb3RoZXIuIFBsZWFzZSBjbGFyaWZ5Lg0KDQpZZXMsIGFueSB0d28gQ0RO cyBjYW4gYmUgaW4gYSB1LWQgcmVsYXRpb25zaGlwICwgYW5kIGlzIGluZGVwZW5kZW50IGZvciBl YWNoIGRpcmVjdGlvbi4NCmllIENETjEgYW5kIENETjIgY2FuIGJlIGluIGEgIHXigJQ+ZCAsICBk 4oCUPnUgLCBvciAgIHUvZDzigJQ+dS9kICByZWxhdGlvbnNoaXAuDQoNClRoaXMgc2hvdWxkIGJl IGVzdGFibGlzaGVkIGJ5IFJGQzY3MDcgYW5kIFJGQzczMzYgKHRoYXQgcmVmZXJzIHRvIHRoZSBj b25jZXB0cyBhbmQgdGVybWlub2xvZ3kgb2YgUkZDNjcwNykuDQpSZWdhcmRpbmcgdGhlIHNwZWNp ZmljIHNpdHVhdGlvbiBvZiDigJx1Q0ROIOKAlD4gZENETi0yIOKAlD5kQ0ROLTPigJ0gaW4gRmln dXJlIDEsIHRoaXMgc2l0dWF0aW9uIGlzIGRpc2N1c3NlZCBpbiBSRkM2NzA3LiBGb3IgZXhhbXBs ZSwgaXQgc2F5czoNCiINCk5vdGUgdGhhdCBpbiB0aGUgY2FzZSBvZiBzdWNjZXNzaXZlIHJlZGly ZWN0aW9ucyAoZS5nLiwgQ0ROMS0tPkNETjItLT5DRE4zKSwgYSBnaXZlbiBDRE4NCiAgIChlLmcu LCBDRE4yKSBtYXkgYWN0IGFzIHRoZSBEb3duc3RyZWFtIENETiBmb3IgYSByZWRpcmVjdGlvbiAo ZS5nLiwNCiAgIENETjEtLT5DRE4yKSBhbmQgYXMgdGhlIFVwc3RyZWFtIENETiBmb3IgdGhlIHN1 YnNlcXVlbnQgcmVkaXJlY3Rpb24NCiAgIG9mIHRoZSBzYW1lIHJlcXVlc3QgKGUuZy4sIENETjIt LT5DRE4zKS4NCuKAnA0KDQpUbyBtYWtlIHRoaW5ncyB2ZXJ5IGNsZWFyIGluIGNkbmktbG9nZ2lu ZyBJIGhhdmUgZG9uZSB0aGUgZm9sbG93aW5nIGVkaXRzOg0KDQoNCk9MRDoNCiINCkluIHR1cm4s IGRDRE4yIGhhcyBhIENETkkgaW50ZXJjb25uZWN0aW9uIHdpdGggZENETjMuDQoiDQpORVc6DQoi DQpJbiB0dXJuLCBkQ0ROMiBoYXMgYSBDRE5JIGludGVyY29ubmVjdGlvbiB3aXRoIGRDRE4tMywg d2hlcmUgZENETi0yIGlzIGFjdGluZyBhcyBhbiB1cHN0cmVhbSBDRE4gcmVsYXRpdmUgdG8gZENE Ti0zIi4NCiINCg0KDQoNCk9MRDoNCuKAnA0KQSBkQ0ROIChlLmcuLCBkQ0ROLTIpIGludGVncmF0 ZXMgdGhlIHJlbGV2YW50IExvZ2dpbmcgaW5mb3JtYXRpb24NCiAgIG9idGFpbmVkIGZyb20gaXRz IGRDRE5zIChpLmUuLCBkQ0ROLTMpIGluIHRoZSBMb2dnaW5nIGluZm9ybWF0aW9uDQoiDQoNCg0K TkVXOg0K4oCcDQpBIGRvd25zdHJlYW0gQ0ROIHJlbGF0aXZlIHRvIHVDRE4gKGUuZy4sIGRDRE4t MikgaW50ZWdyYXRlcyB0aGUgcmVsZXZhbnQgTG9nZ2luZyBpbmZvcm1hdGlvbiBvYnRhaW5lZCBm cm9tIGl0cyBvd24gZG93bnN0cmVhbSBDRE5zIChpLmUuLCBkQ0ROLTMpIGluIHRoZSBMb2dnaW5n IGluZm9ybWF0aW9uDQoiDQoNCg0KDQo+IA0KPiAqIFBhcmFncmFwaCAzLjIgIENETkkgTG9nZ2lu ZyBGaWxlIFN0cnVjdHVyZQ0KPiANCj4gWW91IHN0YXRlIHRoYXQgeW91IGNob3NlIGEgZm9ybWF0 IGFzIGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBXM0MgRUxGIEZvcm1hdC4gSeKAmWQgbGlrZSB0 byBzZWUgYSBzaG9ydCBleHBsYW5hdGlvbiB3aHkgeW91IGNhbiBub3QgdXNlIHRoYXQgZm9ybWF0 LCBhbmQgd2hldGhlciBpdCB3b3VsZCBiZSBhbiBvcHRpb24gdG8gZXh0ZW5kIHRoYXQgZm9ybWF0 IHJhdGhlciB0aGFuIGRlZmluaW5nIGEgbmV3IGZvcm1hdCB0aGF0IGlzIHNsaWdodGx5IGRpZmZl cmVudCBidXQgaXMgZXNzZW50aWFsbHkgYSBmb3JtIGFuZCBjb3VsZCBvdmVyIHRpbWUgYmUgc2ln bmlmaWNhbnRseSBkaWZmZXJlbnQuDQoNClRoZSBXM0MgRUxGIHNwZWNpZmljYXRpb24sIHdoaWxl IGNvbW1vbmx5IHVzZWQsIGlzIHNvbWV3aGF0IHVuZGVyc3BlY2lmaWVkIGFuZCBvbmx5IGEgZHJh ZnQgZG9jdW1lbnQuIFRoZSBkb2N1bWVudCBzYXlzOg0K4oCcDQpUaGlzIGlzIGEgVzNDIFdvcmtp bmcgRHJhZnQgZm9yIHJldmlldyBieSBXM0MgbWVtYmVycyBhbmQgb3RoZXIgaW50ZXJlc3RlZCBw YXJ0aWVzLiBJdCBpcyBhIGRyYWZ0IGRvY3VtZW50IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgVzNDIFdvcmtpbmcgRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gYXMgb3RoZXIgdGhhbiAid29yayBpbiBwcm9ncmVzc+KAnS4NCuKA nA0KU28gaXQgZG9lcyBub3Qgc2VlbSBhcHByb3ByaWF0ZSB0byBzaW1wbHkgcmV1c2UgdGhhdCBz cGVjLCBvciBldmVuIHRvIHVzZSBpdCBhcyBhIHN0YWJsZSBiYXNlIHRvIGV4dGVuZCBmcm9tLg0K DQoNCkJlc2lkZXMsIHdl4oCZdmUgcmVhbGx5IHN0YXJ0ZWQgZnJvbSBFTEYgYW5kIGRpdmVyZ2Vk IHdoZXJlIG5lY2Vzc2FyeSBvciB1c2VmdWwuDQpTZXZlcmFsIG9mIHRoZSBkaXJlY3RpdmVzIHdl IG5lZWRlZCBkbyBub3QgaGF2ZSBhbnkgZXF1aXZhbGVudCBpbiBFTEYuIFF1aXRlIGEgZmV3IGZp ZWxkcyB3ZSBuZWVkZWQgZG8gbm90IGhhdmUgYW4gZXF1aXZhbGVudCBpbiBFTEYsIGFuZC9vciBk byBub3QgaGF2ZSBhIHRvdGFsbHkgdW5hbWJpZ291cyBkZXNjcmlwdGlvbi4NCkFsc28gd2UgbmVl ZGVkIHRvIGJlIGFibGUgdG8gY2FycnkgbG9ncyBmb3Igbm9uLUhUVFAgcHJvdG9jb2xzLg0KDQo+ IA0KPiAqIHBhcmFncmFwaCAzLjMgRGlyZWN0aXZlcw0KPiANCj4gRm9yIHRoZSBJbnRlZ3JpdHkt SGFzaCB5b3Ugd3JpdGU6ICJoYXNoIGZ1bmN0aW9uIG9mIGFsbCBsb2dnaW5nIHJlY29yZHMgYW5k IGRpcmVjdGl2ZXMgdXAgdG8gdGhlIGhhc2gtZGlyZWN0aXZlIGl0c2VsZuKAnS4gSSBoYXZlIG5v dCBzZWVuIHRoYXQgdGhlIGRpcmVjdGl2ZXMgYXJlIGluIGEgc3BlY2lhbCBvcmRlciB3aXRoIHRo ZSBJbnRlZ3JpdHktaGFzdCBhcyBsYXN0IG9uZSwNCg0KVGhlIGRlc2NyaXB0aW9uIG9mIGVhY2gg ZGlyZWN0aXZlIGluY2x1ZGVzIGFuIOKAnG9jY3VyZW5jZeKAnSBzcGVjaWZpY2F0aW9uLCB0aGF0 IGRlZmluZXMgd2hlbiwgaG93IG1hbnkgdGltZXMsIHdoZXJlIHRoYXQgZGlyZWN0aXZlIGNhbiBi ZSB1c2VkLg0KVGhlIOKAnG9jY3VycmVuY2XigJ0gdGV4dCBmb3Ig4oCcSW50ZWdyaXR5LUhhc2ji gJ0gZGlyZWN0aXZlIHNheXM6DQoiV2hlbiBwcmVzZW50LCB0aGUgSW50ZWdyaXR5LUhhc2ggZmll bGQgTVVTVCBiZSB0aGUgbGFzdCBsaW5lIG9mIHRoZSBDRE5JIExvZ2dpbmcgRmlsZS7igJ0NCg0K U28gSSB0aGluayB3ZSBhcmUgY292ZXJlZCBoZXJlLg0KDQo+IHNvIGl0IGFwcGVhcnMgdGhhdCB3 aGVuIHRoZSBpbnRlZ3JpdHktaGFzaCBkaXJlY3RpdmUgaXMgdGhlIHZlcnkgZmlyc3Qgb25lIHRo ZXJlIHdpbGwgYmUgbm8gc2Vuc2libGUgaGFzaC4gVW5sZXNzIHRoZXJlIGlzIGFjdHVhbCBvcmRl ciBpbiB0aGUgZGlyZWN0aXZlcyAod3JpdGUgdGhhdCBkb3duKSBJIHN1Z2dlc3Qg4oCcaGFzIGFs bCBsb2dnaW5nIGluZm9ybWF0aW9uIGFuZCBkaXJlY3RpdmVzIHdpdGggdGhlIGV4Y2VwdGlvbiBv ZiB0aGUgSW50ZWdyaXR5LUhhc2ggZGlyZWN0aXZlIGl0c2VsZuKAnQ0KPiANCj4gKiBQYXJhZ3Jh cGggNy4xIEF1dGhlbnRpY2F0aW9uLCBDb25maWRlbnRpYWxpdHksIEludGVncml0eSBQcm90ZWN0 aW9uDQo+IA0KPiBZb3UgbGVhdmUgb3V0IHRoZSAzZCBBLCBBdXRob3JpemF0aW9uLCBidXQgdGhl biB5b3UgdGFsayBhYm91dCBtdXR1YWwgYXV0aGVudGljYXRpb24gdG8gZGVjaWRlIHdoZXRoZXIg YW4gZW50aXR5IGlzIGF1dGhvcmlzZWQgdG8gcmVjZWl2ZSB0aGUgbG9ncywgc28gSSB0aGluayB5 b3Ugc2hvdWxkIGluc2VydCBpdCB0aGF0IG9uZSB0b28uDQo+IA0KPiBZb3Ugc3RhdGUgdGhhdCB0 aGUgdXNlIG9mIFRMUyBmb3IgdHJhbnNwb3J0IGFsbG93cyBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0 aW9uLCBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSwgdGhhdCBpbiBpdHNlbGYgaXMgbm90 IHRydWUuIFlvdSBuZWVkIFRMUyArIG11dHVhbCBhdXRoZW50aWNhdGlvbiB0byBnZXQgY29uZmlk ZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkuIA0KDQoNCkdvb2QgcG9pbnRzLiBUbyBhZGRyZXNzIHRo ZSB0d28gY29tbWVudHMgYWJvdmUsIEkgaGF2ZSBpbmNvcnBvcmF0ZWQgdGhlIGZvbGxvd2luZyBl ZGl0czoNCg0KSSBzZWUuDQoNCkkgZGlkIHRoZSBmb2xsb3dpbmcgZWRpdHM6DQoNCk9MRDoNCuKA nA0KNy4xLiAgQXV0aGVudGljYXRpb24sIENvbmZpZGVudGlhbGl0eSwgSW50ZWdyaXR5IFByb3Rl Y3Rpb24NCiINCk5FVzoNCuKAnA0KNy4xLiAgQXV0aGVudGljYXRpb24sIEF1dGhvcml6YXRpb24s IENvbmZpZGVudGlhbGl0eSwgSW50ZWdyaXR5IFByb3RlY3Rpb24NCiINCg0KDQpPTEQ6DQrigJwN ClRoZSB1c2Ugb2YgVExTIGZvciB0cmFuc3BvcnQgb2YgdGhlIENETkkgTG9nZ2luZyBmZWVkIGFu ZCBDRE5JDQogICBMb2dnaW5nIEZpbGUgcHVsbCBhbGxvd3M6DQoNCiAgIG8gIHRoZSBkQ0ROIGFu ZCB1Q0ROIHRvIGF1dGhlbnRpY2F0ZSBlYWNoIG90aGVyICh0byBlbnN1cmUgdGhleSBhcmUNCiAg ICAgIHRyYW5zbWl0dGluZy9yZWNlaXZpbmcgQ0ROSSBMb2dnaW5nIEZpbGUgZnJvbSBhbiBhdXRo ZW50aWNhdGVkDQogICAgICBDRE4pDQoNCiAgIG8gIHRoZSBDRE5JIExvZ2dpbmcgaW5mb3JtYXRp b24gdG8gYmUgdHJhbnNtaXR0ZWQgd2l0aA0KICAgICAgY29uZmlkZW50aWFsaXR5DQoNCiAgIG8g IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIENETkkgTG9nZ2luZyBpbmZvcm1hdGlvbiB0byBiZSBwcm90 ZWN0ZWQNCiAgICAgIGR1cmluZyB0aGUgZXhjaGFuZ2UNCuKAnA0KTkVXOg0K4oCcDQpUaGUgdXNl IG9mIFRMUyBmb3IgdHJhbnNwb3J0IG9mIHRoZSBDRE5JIExvZ2dpbmcgZmVlZCBhbmQgQ0ROSQ0K ICAgTG9nZ2luZyBGaWxlIHB1bGwgYWxsb3dzOg0KDQogICBvICB0aGUgZENETiBhbmQgdUNETiB0 byBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciANCg0KYW5kLCBvbmNlIHRoZXkgaGF2ZSBtdXR1YWxs eSBhdXRoZW50aWNhdGVkIGVhY2ggb3RoZXIsIGl0IGFsbG93czoNCg0KICAgbyB0aGUgZENETiBh bmQgdUNETiB0byBhdXRob3JpemUgZWFjaCBvdGhlciAodG8gZW5zdXJlIHRoZXkgYXJlDQogICAg ICB0cmFuc21pdHRpbmcvcmVjZWl2aW5nIENETkkgTG9nZ2luZyBGaWxlIHRvL2Zyb20gYW4gYXV0 aG9yaXplZA0KICAgICAgQ0ROKQ0KDQogICBvICB0aGUgQ0ROSSBMb2dnaW5nIGluZm9ybWF0aW9u IHRvIGJlIHRyYW5zbWl0dGVkIHdpdGgNCiAgICAgIGNvbmZpZGVudGlhbGl0eQ0KDQogICBvICB0 aGUgaW50ZWdyaXR5IG9mIHRoZSBDRE5JIExvZ2dpbmcgaW5mb3JtYXRpb24gdG8gYmUgcHJvdGVj dGVkDQogICAgICBkdXJpbmcgdGhlIGV4Y2hhbmdlDQrigJwNCg0KDQo+IEluIHRoZSB0ZXh0IOKA nEluIGFuIGVudmlyb25tZW50IHdoZXJlIGFueSBzdWNoIHByb3RlY3Rpb24gaXMgcmVxdWlyZWTi gKYu4oCdIFRMUyBpcyBhICJTSE9VTEQgdW5sZXNz4oCmLi7igJ0sIFdoeSBub3Qg4oCcTVVTVCB1 bmxlc3PigKYu4oCdDQoNCldlIGhhdmUgZGlzY3Vzc2VkIHRoaXMgaW4gdGVoIFdvcmtpbmcgR3Jv dXAsIGFuZCBpdCB3YXMgZmVsdCB0aGF0IHRoZSBkZWZpbml0aW9uIG9mIOKAnFNIT1VMROKAnSBh cyBwZXIgUkZDMjExOSBtYXRjaGVzIHdoYXQgc3F1YXJlbHkgd2hhdCB3ZSB3YW50IHRvIHNheSBo ZXJlOiANCiJUaGlzIHdvcmQsIG9yIHRoZSBhZGplY3RpdmUgIlJFQ09NTUVOREVEIiwgbWVhbiB0 aGF0IHRoZXJlDQogIG1heSBleGlzdCB2YWxpZCByZWFzb25zIGluIHBhcnRpY3VsYXIgY2lyY3Vt c3RhbmNlcyB0byBpZ25vcmUgYQ0KICBwYXJ0aWN1bGFyIGl0ZW0sIGJ1dCB0aGUgZnVsbCBpbXBs aWNhdGlvbnMgbXVzdCBiZSB1bmRlcnN0b29kIGFuZA0KICBjYXJlZnVsbHkgd2VpZ2hlZCBiZWZv cmUgY2hvb3NpbmcgYSBkaWZmZXJlbnQgY291cnNlLuKAnQ0KU28gdGhpcyBkb2VzIHNheSB0aGF0 IHlvdSBhcmUgcmVhbGx5IG1lYW50IHRvIHVzZSBUTFMsIGJ1dCBpZiB5b3Ugd2FudCB0byBkbyBz b21ldGhpbmcgZGlmZmVyZW50LCB5b3UgbmVlZCB0byBoYXZlIGEgZ29vZCByZWFzb24gYW5kIHJl YWxseSB1bmRlcnN0YW5kIHdoYXQgeW914oCZcmUgZG9pbmcuDQoNCg0KPiANCj4gKiBwYXJhZ3Jh cGggNy4yIERvUw0KPiANCj4gSSBkb27igJl0IHVuZGVyc3RhbmQgaG93IHRoZSB1c2Ugb2YgVExT IHByb3RlY3RzIGFnYWlucyBEb1MsIG9uIHRoZSBjb250cmFyeSBJIHdvdWxkIHNheSwgdHJ5aW5n IHRvIGVzdGFibGlzaCBhIFRMUyBzZXNzaW9uIGlzIGNvc3RseSwgc28gYW4gZXZpbCBlbnRpdHkg Y291bGQgZWFzaWx5IG1vdW50IGEgRG9TIGJ5IHRyeWluZyB0byBjb25uZWN0IGFuZCBleGNoYW5n ZSBjcnlwdG8gbWF0ZXJpYWwuDQoNCg0KR29vZCBwb2ludC4gSSBjb3JyZWN0ZWQgdGhlIHRleHQ6 DQoNCk9MRDoNCuKAnA0KVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgc3BlY2lmaWMgbWVj aGFuaXNtIHRvIHByb3RlY3QgYWdhaW5zdA0KICAgRGVuaWFsIG9mIFNlcnZpY2UgKERvUykgYXR0 YWNrcyBvbiB0aGUgTG9nZ2luZyBJbnRlcmZhY2UuICBIb3dldmVyLA0KICAgdGhlIENETkkgTG9n Z2luZyBmZWVkIGFuZCBDRE5JIExvZ2dpbmcgcHVsbCBlbmRwb2ludHMgY2FuIGJlDQogICBwcm90 ZWN0ZWQgYWdhaW5zdCBEb1MgYXR0YWNrcyB0aHJvdWdoIHRoZSB1c2Ugb2YgVExTIHRyYW5zcG9y dCBhbmQvb3INCiAgIHZpYSBtZWNoYW5pc21zIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBDRE5J IExvZ2dpbmcgaW50ZXJmYWNlIHN1Y2gNCiAgIGFzIGZpcmV3YWxsaW5nIG9yIHVzZSBvZiBWaXJ0 dWFsIFByaXZhdGUgTmV0d29ya3MgKFZQTnMpLg0KIg0KTkVXOg0K4oCcDQpUaGlzIGRvY3VtZW50 IGRvZXMgbm90IGRlZmluZSBzcGVjaWZpYyBtZWNoYW5pc20gdG8gcHJvdGVjdCBhZ2FpbnN0IERl bmlhbCBvZiBTZXJ2aWNlIChEb1MpIGF0dGFja3Mgb24gdGhlIExvZ2dpbmcgSW50ZXJmYWNlLiBI b3dldmVyLCB0aGUgQ0ROSSBMb2dnaW5nIGZlZWQgYW5kIENETkkgTG9nZ2luZyBwdWxsIGVuZHBv aW50cyBhcmUgdHlwaWNhbGx5IHRvIGJlIGFjY2Vzc2VkIG9ubHkgYnkgYSB2ZXJ5IHNtYWxsIG51 bWJlciBvZiB2YWxpZCByZW1vdGUgZW5kcG9pbnRzIGFuZCB0aGVyZWZvcmUgY2FuIGJlIGVhc2ls eSBwcm90ZWN0ZWQgYWdhaW5zdCBEb1MgYXR0YWNrcyB0aHJvdWdoIHRoZSB1c3VhbCBjb252ZW50 aW9uYWwgRE9TIHByb3RlY3Rpb24gbWVjaGFuaXNtcyBzdWNoIGFzIGZpcmV3YWxsaW5nIG9yIHVz ZSBvZiBWaXJ0dWFsIFByaXZhdGUgTmV0d29ya3MgKFZQTnMpLg0K4oCcDQoNClRoYW5rcyBhZ2Fp bi4NCg0KRnJhbmNvaXMNCg0KPiANCj4gDQo+IEtsYWFzDQo+IA0KPiANCj4gLS0NCj4gS2xhYXMg V2llcmVuZ2ENCj4gSWRlbnRpdHkgQXJjaGl0ZWN0DQo+IENpc2NvIENsb3VkIFNlcnZpY2VzDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQoNCg== From nobody Wed Mar 4 02:40: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 398601A1A9F; Wed, 4 Mar 2015 02:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, 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 zDxdLB3uA50g; Wed, 4 Mar 2015 02:40:07 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B5F1A1A4E; Wed, 4 Mar 2015 02:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1718; q=dns/txt; s=iport; t=1425465608; x=1426675208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rc1+4+IraZiKjI5vn9jNr5BgUNFbGDrsi4tYBequOoA=; b=TCbkRZLEVqc/wzDbwScihwSHItKrOxgxnuIiohkHyu5UtZa0/t1U11// 8hWJiusemJbYtl8iWEy/e5sCyW0Uq8yOWAdiCE+wF2oiewwi7383nTxHJ zPO8cwWk+mID5DEBXZ7nfm1cdyevqqPb3JnUlUNCRmgT9PekCdqHQFQAZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJBwBd4PZU/5xdJa1agwKBML5liCICgSNNAQEBAQEBfIQQAQEEcgcQAgEIDjgyJQIEDog01xIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixKEFSYzB4MXgRQBBI9/h1GBe4EaEYMUi2mDQCODboF6OX8BAQE X-IronPort-AV: E=Sophos;i="5.09,687,1418083200"; d="scan'208";a="400765494" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 04 Mar 2015 10:40:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t24Ae5qE007992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 10:40:05 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.223]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 04:40:04 -0600 From: "Klaas Wierenga (kwiereng)" To: Daryl Malas Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFZzzy/wAgAG5RQCAFx8pAA== Date: Wed, 4 Mar 2015 10:40:04 +0000 Message-ID: <07492AC0-54CE-4C57-8342-91A8C9597678@cisco.com> References: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.84.252] Content-Type: text/plain; charset="Windows-1252" Content-ID: <46164A91CF10AA4B8245E7293F17532E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-logging.all@tools.ietf.org" , "Francois Le Faucheur \(flefauch\)" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 10:40:08 -0000 Hi Daryl, Apologies for my late reply, I completed missed your e-mail and Francois=92= reply propelled it back to the top of my inbox. >>>=20 >>>=20 >>>=20 >>> Detailed comments: >>>=20 >>> * Introduction and Figure 1: What is not clear to me from the text is >>> whether there is any functional difference between an uCDN and an >>> dCDN,or that they just happen to be in a hierarchical relation to each >>> other. I could also find no reference to that in RFC7336. The fact tha= t >>> in Figure 1 dCDN-2 is not also labeled as uCDN-2 led me to believe that >>> there is a functional difference. However from the text it appears that >>> any two DCNs can be in an u-d relation to each other. Please clarify. >=20 > In Figure 1 of RFC 7336, you will notice the interfaces are indicated as > bi-directional. I believe the spirit of this is to provide a hierarchal > perspective. In any case, can you please clarify your =B3security=B2 rel= ated > concerns relative to this scenario? So far, you have only indicated a > question of whether a downstream CDN can also be an upstream CDN. What i= s > your related security question if the function changes relative to > exchanges via the logging interfaces? If this is a terminology question, > I think it should have been addressed with regards to 7336. >=20 > To be clear, I=B9m just asking for more clarity for the authors to proper= ly > address this question. On my side there was no security related concern to it. I was just reading = through the text and was unclear on this. To me there was a difference in w= hat the text suggested and what the figure looked like, if that is clarifie= d I am happy ;-) Klaas= From nobody Wed Mar 4 02: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 3E14F1A1AA2; Wed, 4 Mar 2015 02:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, 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 RkQCRKmqFQry; Wed, 4 Mar 2015 02:48:11 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D901A00FA; Wed, 4 Mar 2015 02:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13248; q=dns/txt; s=iport; t=1425466091; x=1426675691; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RDnvVCX2VV521mwnArd7GLfjcGJBWGhBJFe+4yOJOd0=; b=kGGHoiK2YokXVO3l7lwSnl98Bx1KS21YJ9YOQo6Jyk75GBmrIWu88+B6 1P/8kY0avyghN6jLSpLvqkzxXGdHXvYjqKx+CfSTs/DuC2PgFrmmnWkwS bECuuPJsNZmJzwA/e6DpcZLO7GFAPdAMzvywTYnUltKDcG0kAORg3zQr1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKCQBz4vZU/5RdJa1RCYMCUk4MBIMHu16IIgIcgQdNAQEBAQEBfIQPAQEBAwEjBA0+BwULAgEGAhgCAiYCAgIwFRACBA4FiCcIn32cbJopAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXGEE1sHgmgvgRQBBI9/hXuDUYEagyWCU4kWg0AjggEBHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,687,1418083200"; d="scan'208";a="400747181" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 04 Mar 2015 10:48:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t24Am9rf027567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 10:48:09 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.223]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 04:48:09 -0600 From: "Klaas Wierenga (kwiereng)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFZ0MoCWAgAAGh4A= Date: Wed, 4 Mar 2015 10:48:08 +0000 Message-ID: <39043BA8-EE63-4B8B-9257-0660429F0897@cisco.com> References: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> <57CC830A-5092-4BA3-9628-90B148951A16@cisco.com> In-Reply-To: <57CC830A-5092-4BA3-9628-90B148951A16@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.84.252] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-logging.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 10:48:15 -0000 SGkgRnJhbmNvaXMsDQoNCg0KPiBPbiAwNCBNYXIgMjAxNSwgYXQgMTE6MjQsIEZyYW5jb2lzIExl IEZhdWNoZXVyIChmbGVmYXVjaCkgPGZsZWZhdWNoQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBI ZWxsbyBLbGFhcywNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFByb3Bvc2VkIHJlc29s dXRpb24gb2YgY29tbWVudHMgYmVsb3c6DQo+IA0KPj4gT24gMTMgRmViIDIwMTUsIGF0IDE3OjA1 LCBLbGFhcyBXaWVyZW5nYSAoa3dpZXJlbmcpIDxrd2llcmVuZ0BjaXNjby5jb20+IHdyb3RlOg0K Pj4gDQo+PiBIaSwNCj4+IA0KPj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29t bWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlICBzZWN1 cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91 bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29t bWVudHMuDQo+PiANCj4+IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBsb2dnaW5nIGZvcm1h dCBhbmQgdGhlIGV4Y2hhbmdlIHByb3RvY29sIGZvciBsb2dnaW5nIGluZm9ybWF0aW9uIGJldHdl ZW4gdXBzdHJlYW0gYW5kIGRvd25zdHJlYW0gQ0ROcyB0aGF0IGFyZSBpbnRlcmNvbm5lY3RlZCB1 c2luZyB0aGUgQ0ROIGludGVyY29ubmVjdGlvbiBmcmFtZXdvcmsuDQo+PiANCj4+IFRoZSBkb2N1 bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGVhc3kgdG8gcmVhZC4gSSBoYXZlIGZldyBpc3N1ZXMg d2l0aCB0aGUgbWFpbiB0ZXh0LCBidXQgZG8gaGF2ZSBzb21lIGNvbmNlcm5zIGFib3V0IHRoZSBz ZWN1cml0eSBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gSSB0aGVyZWZvcmUgY29uc2lkZXIg dGhlIGRvY3VtZW50IOKAnHJlYWR5IHdpdGggaXNzdWVz4oCdDQo+PiANCj4+IERldGFpbGVkIGNv bW1lbnRzOg0KPj4gDQo+PiAqIEludHJvZHVjdGlvbiBhbmQgRmlndXJlIDE6IFdoYXQgaXMgbm90 IGNsZWFyIHRvIG1lIGZyb20gdGhlIHRleHQgaXMgd2hldGhlciB0aGVyZSBpcyBhbnkgZnVuY3Rp b25hbCBkaWZmZXJlbmNlIGJldHdlZW4gYW4gdUNETiBhbmQgYW4gZENETixvciB0aGF0IHRoZXkg anVzdCBoYXBwZW4gdG8gYmUgaW4gYSBoaWVyYXJjaGljYWwgcmVsYXRpb24gdG8gZWFjaCBvdGhl ci4gIEkgY291bGQgYWxzbyBmaW5kIG5vIHJlZmVyZW5jZSB0byB0aGF0IGluIFJGQzczMzYuIFRo ZSBmYWN0IHRoYXQgaW4gRmlndXJlIDEgZENETi0yIGlzIG5vdCBhbHNvIGxhYmVsZWQgYXMgdUNE Ti0yIGxlZCBtZSB0byBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgYSBmdW5jdGlvbmFsIGRpZmZlcmVu Y2UuIEhvd2V2ZXIgZnJvbSB0aGUgdGV4dCBpdCBhcHBlYXJzIHRoYXQgYW55IHR3byBEQ05zIGNh biBiZSBpbiBhbiB1LWQgcmVsYXRpb24gdG8gZWFjaCBvdGhlci4gUGxlYXNlIGNsYXJpZnkuDQo+ IA0KPiBZZXMsIGFueSB0d28gQ0ROcyBjYW4gYmUgaW4gYSB1LWQgcmVsYXRpb25zaGlwICwgYW5k IGlzIGluZGVwZW5kZW50IGZvciBlYWNoIGRpcmVjdGlvbi4NCj4gaWUgQ0ROMSBhbmQgQ0ROMiBj YW4gYmUgaW4gYSAgdeKAlD5kICwgIGTigJQ+dSAsIG9yICAgdS9kPOKAlD51L2QgIHJlbGF0aW9u c2hpcC4NCj4gDQo+IFRoaXMgc2hvdWxkIGJlIGVzdGFibGlzaGVkIGJ5IFJGQzY3MDcgYW5kIFJG QzczMzYgKHRoYXQgcmVmZXJzIHRvIHRoZSBjb25jZXB0cyBhbmQgdGVybWlub2xvZ3kgb2YgUkZD NjcwNykuDQo+IFJlZ2FyZGluZyB0aGUgc3BlY2lmaWMgc2l0dWF0aW9uIG9mIOKAnHVDRE4g4oCU PiBkQ0ROLTIg4oCUPmRDRE4tM+KAnSBpbiBGaWd1cmUgMSwgdGhpcyBzaXR1YXRpb24gaXMgZGlz Y3Vzc2VkIGluIFJGQzY3MDcuIEZvciBleGFtcGxlLCBpdCBzYXlzOg0KPiAiDQo+IE5vdGUgdGhh dCBpbiB0aGUgY2FzZSBvZiBzdWNjZXNzaXZlIHJlZGlyZWN0aW9ucyAoZS5nLiwgQ0ROMS0tPkNE TjItLT5DRE4zKSwgYSBnaXZlbiBDRE4NCj4gICAoZS5nLiwgQ0ROMikgbWF5IGFjdCBhcyB0aGUg RG93bnN0cmVhbSBDRE4gZm9yIGEgcmVkaXJlY3Rpb24gKGUuZy4sDQo+ICAgQ0ROMS0tPkNETjIp IGFuZCBhcyB0aGUgVXBzdHJlYW0gQ0ROIGZvciB0aGUgc3Vic2VxdWVudCByZWRpcmVjdGlvbg0K PiAgIG9mIHRoZSBzYW1lIHJlcXVlc3QgKGUuZy4sIENETjItLT5DRE4zKS4NCj4g4oCcDQo+IA0K PiBUbyBtYWtlIHRoaW5ncyB2ZXJ5IGNsZWFyIGluIGNkbmktbG9nZ2luZyBJIGhhdmUgZG9uZSB0 aGUgZm9sbG93aW5nIGVkaXRzOg0KPiANCj4gDQo+IE9MRDoNCj4gIg0KPiBJbiB0dXJuLCBkQ0RO MiBoYXMgYSBDRE5JIGludGVyY29ubmVjdGlvbiB3aXRoIGRDRE4zLg0KPiAiDQo+IE5FVzoNCj4g Ig0KPiBJbiB0dXJuLCBkQ0ROMiBoYXMgYSBDRE5JIGludGVyY29ubmVjdGlvbiB3aXRoIGRDRE4t Mywgd2hlcmUgZENETi0yIGlzIGFjdGluZyBhcyBhbiB1cHN0cmVhbSBDRE4gcmVsYXRpdmUgdG8g ZENETi0zIi4NCj4gIg0KPiANCj4gDQo+IE9MRDoNCj4g4oCcDQo+IEEgZENETiAoZS5nLiwgZENE Ti0yKSBpbnRlZ3JhdGVzIHRoZSByZWxldmFudCBMb2dnaW5nIGluZm9ybWF0aW9uDQo+ICAgb2J0 YWluZWQgZnJvbSBpdHMgZENETnMgKGkuZS4sIGRDRE4tMykgaW4gdGhlIExvZ2dpbmcgaW5mb3Jt YXRpb24NCj4gIg0KPiANCj4gDQo+IE5FVzoNCj4g4oCcDQo+IEEgZG93bnN0cmVhbSBDRE4gcmVs YXRpdmUgdG8gdUNETiAoZS5nLiwgZENETi0yKSBpbnRlZ3JhdGVzIHRoZSByZWxldmFudCBMb2dn aW5nIGluZm9ybWF0aW9uIG9idGFpbmVkIGZyb20gaXRzIG93biBkb3duc3RyZWFtIENETnMgKGku ZS4sIGRDRE4tMykgaW4gdGhlIExvZ2dpbmcgaW5mb3JtYXRpb24NCj4g4oCcDQo+IA0KDQpwZXJm ZWN0LCB0aGFua3MNCg0KPiANCj4+IA0KPj4gKiBQYXJhZ3JhcGggMy4yICBDRE5JIExvZ2dpbmcg RmlsZSBTdHJ1Y3R1cmUNCj4+IA0KPj4gWW91IHN0YXRlIHRoYXQgeW91IGNob3NlIGEgZm9ybWF0 IGFzIGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBXM0MgRUxGIEZvcm1hdC4gSeKAmWQgbGlrZSB0 byBzZWUgYSBzaG9ydCBleHBsYW5hdGlvbiB3aHkgeW91IGNhbiBub3QgdXNlIHRoYXQgZm9ybWF0 LCBhbmQgd2hldGhlciBpdCB3b3VsZCBiZSBhbiBvcHRpb24gdG8gZXh0ZW5kIHRoYXQgZm9ybWF0 IHJhdGhlciB0aGFuIGRlZmluaW5nIGEgbmV3IGZvcm1hdCB0aGF0IGlzIHNsaWdodGx5IGRpZmZl cmVudCBidXQgaXMgZXNzZW50aWFsbHkgYSBmb3JtIGFuZCBjb3VsZCBvdmVyIHRpbWUgYmUgc2ln bmlmaWNhbnRseSBkaWZmZXJlbnQuDQo+IA0KPiBUaGUgVzNDIEVMRiBzcGVjaWZpY2F0aW9uLCB3 aGlsZSBjb21tb25seSB1c2VkLCBpcyBzb21ld2hhdCB1bmRlcnNwZWNpZmllZCBhbmQgb25seSBh IGRyYWZ0IGRvY3VtZW50LiBUaGUgZG9jdW1lbnQgc2F5czoNCj4g4oCcDQo+IFRoaXMgaXMgYSBX M0MgV29ya2luZyBEcmFmdCBmb3IgcmV2aWV3IGJ5IFczQyBtZW1iZXJzIGFuZCBvdGhlciBpbnRl cmVzdGVkIHBhcnRpZXMuIEl0IGlzIGEgZHJhZnQgZG9jdW1lbnQgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBXM0MgV29ya2luZyBEcmFmdHMgYXMgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBhcyBvdGhlciB0aGFuICJ3b3JrIGluIHByb2dyZXNz 4oCdLg0KPiDigJwNCj4gU28gaXQgZG9lcyBub3Qgc2VlbSBhcHByb3ByaWF0ZSB0byBzaW1wbHkg cmV1c2UgdGhhdCBzcGVjLCBvciBldmVuIHRvIHVzZSBpdCBhcyBhIHN0YWJsZSBiYXNlIHRvIGV4 dGVuZCBmcm9tLg0KPiANCj4gDQo+IEJlc2lkZXMsIHdl4oCZdmUgcmVhbGx5IHN0YXJ0ZWQgZnJv bSBFTEYgYW5kIGRpdmVyZ2VkIHdoZXJlIG5lY2Vzc2FyeSBvciB1c2VmdWwuDQo+IFNldmVyYWwg b2YgdGhlIGRpcmVjdGl2ZXMgd2UgbmVlZGVkIGRvIG5vdCBoYXZlIGFueSBlcXVpdmFsZW50IGlu IEVMRi4gUXVpdGUgYSBmZXcgZmllbGRzIHdlIG5lZWRlZCBkbyBub3QgaGF2ZSBhbiBlcXVpdmFs ZW50IGluIEVMRiwgYW5kL29yIGRvIG5vdCBoYXZlIGEgdG90YWxseSB1bmFtYmlnb3VzIGRlc2Ny aXB0aW9uLg0KPiBBbHNvIHdlIG5lZWRlZCB0byBiZSBhYmxlIHRvIGNhcnJ5IGxvZ3MgZm9yIG5v bi1IVFRQIHByb3RvY29scy4NCg0Kb2ssIHRoYXQgaXMgYSBjb252aW5jaW5nIGFyZ3VtZW50LiBI b3cgYWJvdXQgaW5jbHVkaW5nIGEgc3RhdGVtZW50IHRvIHRoYXQgZXh0ZW50LCBzb21ldGhpbmcg YWxvbmcgdGhlIGxpbmVzIG9mOiDigJx3ZSB0b29rIEVMRiBhcyBhIHN0YXJ0aW5nIHBvaW50IGFu ZCByZXVzZWQgd2hlcmUgcG9zc2libGUgYW5kIGV4cGFuZGVkIHdoZW4gbmVjZXNzYXJ54oCdDQoN Cj4gDQo+PiANCj4+ICogcGFyYWdyYXBoIDMuMyBEaXJlY3RpdmVzDQo+PiANCj4+IEZvciB0aGUg SW50ZWdyaXR5LUhhc2ggeW91IHdyaXRlOiAiaGFzaCBmdW5jdGlvbiBvZiBhbGwgbG9nZ2luZyBy ZWNvcmRzIGFuZCBkaXJlY3RpdmVzIHVwIHRvIHRoZSBoYXNoLWRpcmVjdGl2ZSBpdHNlbGbigJ0u IEkgaGF2ZSBub3Qgc2VlbiB0aGF0IHRoZSBkaXJlY3RpdmVzIGFyZSBpbiBhIHNwZWNpYWwgb3Jk ZXIgd2l0aCB0aGUgSW50ZWdyaXR5LWhhc3QgYXMgbGFzdCBvbmUsDQo+IA0KPiBUaGUgZGVzY3Jp cHRpb24gb2YgZWFjaCBkaXJlY3RpdmUgaW5jbHVkZXMgYW4g4oCcb2NjdXJlbmNl4oCdIHNwZWNp ZmljYXRpb24sIHRoYXQgZGVmaW5lcyB3aGVuLCBob3cgbWFueSB0aW1lcywgd2hlcmUgdGhhdCBk aXJlY3RpdmUgY2FuIGJlIHVzZWQuDQo+IFRoZSDigJxvY2N1cnJlbmNl4oCdIHRleHQgZm9yIOKA nEludGVncml0eS1IYXNo4oCdIGRpcmVjdGl2ZSBzYXlzOg0KPiAiV2hlbiBwcmVzZW50LCB0aGUg SW50ZWdyaXR5LUhhc2ggZmllbGQgTVVTVCBiZSB0aGUgbGFzdCBsaW5lIG9mIHRoZSBDRE5JIExv Z2dpbmcgRmlsZS7igJ0NCj4gDQo+IFNvIEkgdGhpbmsgd2UgYXJlIGNvdmVyZWQgaGVyZS4NCg0K eXVwLCBJIG1pc3NlZCB0aGF0LCBzb3JyeSA7LSkNCg0KPiANCj4+IHNvIGl0IGFwcGVhcnMgdGhh dCB3aGVuIHRoZSBpbnRlZ3JpdHktaGFzaCBkaXJlY3RpdmUgaXMgdGhlIHZlcnkgZmlyc3Qgb25l IHRoZXJlIHdpbGwgYmUgbm8gc2Vuc2libGUgaGFzaC4gVW5sZXNzIHRoZXJlIGlzIGFjdHVhbCBv cmRlciBpbiB0aGUgZGlyZWN0aXZlcyAod3JpdGUgdGhhdCBkb3duKSBJIHN1Z2dlc3Qg4oCcaGFz IGFsbCBsb2dnaW5nIGluZm9ybWF0aW9uIGFuZCBkaXJlY3RpdmVzIHdpdGggdGhlIGV4Y2VwdGlv biBvZiB0aGUgSW50ZWdyaXR5LUhhc2ggZGlyZWN0aXZlIGl0c2VsZuKAnQ0KPj4gDQo+PiAqIFBh cmFncmFwaCA3LjEgQXV0aGVudGljYXRpb24sIENvbmZpZGVudGlhbGl0eSwgSW50ZWdyaXR5IFBy b3RlY3Rpb24NCj4+IA0KPj4gWW91IGxlYXZlIG91dCB0aGUgM2QgQSwgQXV0aG9yaXphdGlvbiwg YnV0IHRoZW4geW91IHRhbGsgYWJvdXQgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIHRvIGRlY2lkZSB3 aGV0aGVyIGFuIGVudGl0eSBpcyBhdXRob3Jpc2VkIHRvIHJlY2VpdmUgdGhlIGxvZ3MsIHNvIEkg dGhpbmsgeW91IHNob3VsZCBpbnNlcnQgaXQgdGhhdCBvbmUgdG9vLg0KPj4gDQo+PiBZb3Ugc3Rh dGUgdGhhdCB0aGUgdXNlIG9mIFRMUyBmb3IgdHJhbnNwb3J0IGFsbG93cyBmb3IgbXV0dWFsIGF1 dGhlbnRpY2F0aW9uLCBjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSwgdGhhdCBpbiBpdHNl bGYgaXMgbm90IHRydWUuIFlvdSBuZWVkIFRMUyArIG11dHVhbCBhdXRoZW50aWNhdGlvbiB0byBn ZXQgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkuIA0KPiANCj4gDQo+IEdvb2QgcG9pbnRz LiBUbyBhZGRyZXNzIHRoZSB0d28gY29tbWVudHMgYWJvdmUsIEkgaGF2ZSBpbmNvcnBvcmF0ZWQg dGhlIGZvbGxvd2luZyBlZGl0czoNCj4gDQo+IEkgc2VlLg0KPiANCj4gSSBkaWQgdGhlIGZvbGxv d2luZyBlZGl0czoNCj4gDQo+IE9MRDoNCj4g4oCcDQo+IDcuMS4gIEF1dGhlbnRpY2F0aW9uLCBD b25maWRlbnRpYWxpdHksIEludGVncml0eSBQcm90ZWN0aW9uDQo+ICINCj4gTkVXOg0KPiDigJwN Cj4gNy4xLiAgQXV0aGVudGljYXRpb24sIEF1dGhvcml6YXRpb24sIENvbmZpZGVudGlhbGl0eSwg SW50ZWdyaXR5IFByb3RlY3Rpb24NCj4gIg0KPiANCj4gDQo+IE9MRDoNCj4g4oCcDQo+IFRoZSB1 c2Ugb2YgVExTIGZvciB0cmFuc3BvcnQgb2YgdGhlIENETkkgTG9nZ2luZyBmZWVkIGFuZCBDRE5J DQo+ICAgTG9nZ2luZyBGaWxlIHB1bGwgYWxsb3dzOg0KPiANCj4gICBvICB0aGUgZENETiBhbmQg dUNETiB0byBhdXRoZW50aWNhdGUgZWFjaCBvdGhlciAodG8gZW5zdXJlIHRoZXkgYXJlDQo+ICAg ICAgdHJhbnNtaXR0aW5nL3JlY2VpdmluZyBDRE5JIExvZ2dpbmcgRmlsZSBmcm9tIGFuIGF1dGhl bnRpY2F0ZWQNCj4gICAgICBDRE4pDQo+IA0KPiAgIG8gIHRoZSBDRE5JIExvZ2dpbmcgaW5mb3Jt YXRpb24gdG8gYmUgdHJhbnNtaXR0ZWQgd2l0aA0KPiAgICAgIGNvbmZpZGVudGlhbGl0eQ0KPiAN Cj4gICBvICB0aGUgaW50ZWdyaXR5IG9mIHRoZSBDRE5JIExvZ2dpbmcgaW5mb3JtYXRpb24gdG8g YmUgcHJvdGVjdGVkDQo+ICAgICAgZHVyaW5nIHRoZSBleGNoYW5nZQ0KPiDigJwNCj4gTkVXOg0K PiDigJwNCj4gVGhlIHVzZSBvZiBUTFMgZm9yIHRyYW5zcG9ydCBvZiB0aGUgQ0ROSSBMb2dnaW5n IGZlZWQgYW5kIENETkkNCj4gICBMb2dnaW5nIEZpbGUgcHVsbCBhbGxvd3M6DQo+IA0KPiAgIG8g IHRoZSBkQ0ROIGFuZCB1Q0ROIHRvIGF1dGhlbnRpY2F0ZSBlYWNoIG90aGVyIA0KPiANCj4gYW5k LCBvbmNlIHRoZXkgaGF2ZSBtdXR1YWxseSBhdXRoZW50aWNhdGVkIGVhY2ggb3RoZXIsIGl0IGFs bG93czoNCj4gDQo+ICAgbyB0aGUgZENETiBhbmQgdUNETiB0byBhdXRob3JpemUgZWFjaCBvdGhl ciAodG8gZW5zdXJlIHRoZXkgYXJlDQo+ICAgICAgdHJhbnNtaXR0aW5nL3JlY2VpdmluZyBDRE5J IExvZ2dpbmcgRmlsZSB0by9mcm9tIGFuIGF1dGhvcml6ZWQNCj4gICAgICBDRE4pDQo+IA0KPiAg IG8gIHRoZSBDRE5JIExvZ2dpbmcgaW5mb3JtYXRpb24gdG8gYmUgdHJhbnNtaXR0ZWQgd2l0aA0K PiAgICAgIGNvbmZpZGVudGlhbGl0eQ0KPiANCj4gICBvICB0aGUgaW50ZWdyaXR5IG9mIHRoZSBD RE5JIExvZ2dpbmcgaW5mb3JtYXRpb24gdG8gYmUgcHJvdGVjdGVkDQo+ICAgICAgZHVyaW5nIHRo ZSBleGNoYW5nZQ0KPiDigJwNCj4gDQoNCnRoYXQgd29ya3MgZm9yIG1lDQoNCj4gDQo+PiBJbiB0 aGUgdGV4dCDigJxJbiBhbiBlbnZpcm9ubWVudCB3aGVyZSBhbnkgc3VjaCBwcm90ZWN0aW9uIGlz IHJlcXVpcmVk4oCmLuKAnSBUTFMgaXMgYSAiU0hPVUxEIHVubGVzc+KApi4u4oCdLCBXaHkgbm90 IOKAnE1VU1QgdW5sZXNz4oCmLuKAnQ0KPiANCj4gV2UgaGF2ZSBkaXNjdXNzZWQgdGhpcyBpbiB0 ZWggV29ya2luZyBHcm91cCwgYW5kIGl0IHdhcyBmZWx0IHRoYXQgdGhlIGRlZmluaXRpb24gb2Yg 4oCcU0hPVUxE4oCdIGFzIHBlciBSRkMyMTE5IG1hdGNoZXMgd2hhdCBzcXVhcmVseSB3aGF0IHdl IHdhbnQgdG8gc2F5IGhlcmU6IA0KPiAiVGhpcyB3b3JkLCBvciB0aGUgYWRqZWN0aXZlICJSRUNP TU1FTkRFRCIsIG1lYW4gdGhhdCB0aGVyZQ0KPiAgbWF5IGV4aXN0IHZhbGlkIHJlYXNvbnMgaW4g cGFydGljdWxhciBjaXJjdW1zdGFuY2VzIHRvIGlnbm9yZSBhDQo+ICBwYXJ0aWN1bGFyIGl0ZW0s IGJ1dCB0aGUgZnVsbCBpbXBsaWNhdGlvbnMgbXVzdCBiZSB1bmRlcnN0b29kIGFuZA0KPiAgY2Fy ZWZ1bGx5IHdlaWdoZWQgYmVmb3JlIGNob29zaW5nIGEgZGlmZmVyZW50IGNvdXJzZS7igJ0NCj4g U28gdGhpcyBkb2VzIHNheSB0aGF0IHlvdSBhcmUgcmVhbGx5IG1lYW50IHRvIHVzZSBUTFMsIGJ1 dCBpZiB5b3Ugd2FudCB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50LCB5b3UgbmVlZCB0byBoYXZl IGEgZ29vZCByZWFzb24gYW5kIHJlYWxseSB1bmRlcnN0YW5kIHdoYXQgeW914oCZcmUgZG9pbmcu DQoNCm9rLCBpZiB0aGF0IGlzIHRoZSBXRyBjb25zZW5zdXMNCg0KPj4gDQo+PiAqIHBhcmFncmFw aCA3LjIgRG9TDQo+PiANCj4+IEkgZG9u4oCZdCB1bmRlcnN0YW5kIGhvdyB0aGUgdXNlIG9mIFRM UyBwcm90ZWN0cyBhZ2FpbnMgRG9TLCBvbiB0aGUgY29udHJhcnkgSSB3b3VsZCBzYXksIHRyeWlu ZyB0byBlc3RhYmxpc2ggYSBUTFMgc2Vzc2lvbiBpcyBjb3N0bHksIHNvIGFuIGV2aWwgZW50aXR5 IGNvdWxkIGVhc2lseSBtb3VudCBhIERvUyBieSB0cnlpbmcgdG8gY29ubmVjdCBhbmQgZXhjaGFu Z2UgY3J5cHRvIG1hdGVyaWFsLg0KPiANCj4gDQo+IEdvb2QgcG9pbnQuIEkgY29ycmVjdGVkIHRo ZSB0ZXh0Og0KPiANCj4gT0xEOg0KPiDigJwNCj4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZp bmUgc3BlY2lmaWMgbWVjaGFuaXNtIHRvIHByb3RlY3QgYWdhaW5zdA0KPiAgIERlbmlhbCBvZiBT ZXJ2aWNlIChEb1MpIGF0dGFja3Mgb24gdGhlIExvZ2dpbmcgSW50ZXJmYWNlLiAgSG93ZXZlciwN Cj4gICB0aGUgQ0ROSSBMb2dnaW5nIGZlZWQgYW5kIENETkkgTG9nZ2luZyBwdWxsIGVuZHBvaW50 cyBjYW4gYmUNCj4gICBwcm90ZWN0ZWQgYWdhaW5zdCBEb1MgYXR0YWNrcyB0aHJvdWdoIHRoZSB1 c2Ugb2YgVExTIHRyYW5zcG9ydCBhbmQvb3INCj4gICB2aWEgbWVjaGFuaXNtcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGUgQ0ROSSBMb2dnaW5nIGludGVyZmFjZSBzdWNoDQo+ICAgYXMgZmlyZXdh bGxpbmcgb3IgdXNlIG9mIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrcyAoVlBOcykuDQo+ICINCj4g TkVXOg0KPiDigJwNCj4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgc3BlY2lmaWMgbWVj aGFuaXNtIHRvIHByb3RlY3QgYWdhaW5zdCBEZW5pYWwgb2YgU2VydmljZSAoRG9TKSBhdHRhY2tz IG9uIHRoZSBMb2dnaW5nIEludGVyZmFjZS4gSG93ZXZlciwgdGhlIENETkkgTG9nZ2luZyBmZWVk IGFuZCBDRE5JIExvZ2dpbmcgcHVsbCBlbmRwb2ludHMgYXJlIHR5cGljYWxseSB0byBiZSBhY2Nl c3NlZCBvbmx5IGJ5IGEgdmVyeSBzbWFsbCBudW1iZXIgb2YgdmFsaWQgcmVtb3RlIGVuZHBvaW50 cyBhbmQgdGhlcmVmb3JlIGNhbiBiZSBlYXNpbHkgcHJvdGVjdGVkIGFnYWluc3QgRG9TIGF0dGFj a3MgdGhyb3VnaCB0aGUgdXN1YWwgY29udmVudGlvbmFsIERPUyBwcm90ZWN0aW9uIG1lY2hhbmlz bXMgc3VjaCBhcyBmaXJld2FsbGluZyBvciB1c2Ugb2YgVmlydHVhbCBQcml2YXRlIE5ldHdvcmtz IChWUE5zKS4NCj4g4oCcDQoNCg0KeWVzLCB0aGF0IG1ha2VzIG11Y2ggbW9yZSBzZW5zZSB0byBt ZSENCg0KS2xhYXMNCg0KPiANCj4gVGhhbmtzIGFnYWluLg0KPiANCj4gRnJhbmNvaXMNCj4gDQo+ PiANCj4+IA0KPj4gS2xhYXMNCj4+IA0KPj4gDQo+PiAtLQ0KPj4gS2xhYXMgV2llcmVuZ2ENCj4+ IElkZW50aXR5IEFyY2hpdGVjdA0KPj4gQ2lzY28gQ2xvdWQgU2VydmljZXMNCg0K From nobody Wed Mar 4 12:34:53 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 B61F01ACE97 for ; Wed, 4 Mar 2015 12:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 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_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 ylSKhcGtmDxD for ; Wed, 4 Mar 2015 12:34:42 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 18B521ACE8E for ; Wed, 4 Mar 2015 12:34:39 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t24KYarA030635 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Mar 2015 15:34:37 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t24KYarA030635 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1425501278; bh=wksNDGEDePv8Mx4MV//JAudWQsw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lzGgP/p/au8QryUSsSBmsEuwZgN67FvTv81PCCBh8cBO/UgxNSUGtG32l1/DP5nhf C8fGjB1G4dyEYfTyiapYecik+v9uoiV76DMUA0pO9fWnmgzxQ6Q5qGKWD69k625qks 9lyKiusZOBH1yzrEEtC4WBiKrbwLQNR5LFW5bGF8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com t24KYarA030635 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 4 Mar 2015 15:34:23 -0500 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t24KYEXF020982 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 15:34:14 -0500 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub11.corp.emc.com (10.254.92.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 4 Mar 2015 15:34:14 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.139]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0224.002; Wed, 4 Mar 2015 15:34:13 -0500 From: "Moriarty, Kathleen" To: Shawn M Emery Thread-Topic: [secdir] Review of draft-ietf-ccamp-rwa-wson-encode-27 Thread-Index: AQHQTzapWwcNfTe880Sp4vIqijg1vp0M1rl5 Date: Wed, 4 Mar 2015 20:34:13 +0000 Message-ID: <650AAA60-37A1-435E-B738-63D73B101B16@emc.com> References: <54AA17B0.40500@oracle.com>,<54EAD095.2000200@oracle.com> In-Reply-To: <54EAD095.2000200@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-ccamp-rwa-wson-encode-27 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, 04 Mar 2015 20:34:48 -0000 Hi Shawn, Thanks for your review of the draft, it was helpful. One comment inline. Sent from my iPhone > On Feb 23, 2015, at 2:02 AM, "Shawn M Emery" wro= te: >=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 >=20 > The draft specifies an encoding scheme for information on a Wavelength Sw= itched Optical Network > (WSON). Specifically, information that is used for Routing and Wavelengt= h Assignment (RWA). >=20 > The security considerations section does exist and discloses that the dra= ft does not impose > any security considerations in itself, but does admit that documents that= reference this draft > would have considerations for privacy, spoofing, and tampering of any ass= ociated data. I agree > with this assertion. >=20 > General comments: >=20 > None. >=20 > Editorial comments: >=20 > Usually the Abstract is the first section in the draft. I think this is from a template as I've seen this a few times. If the RFC = editor is okay with it... > The abbreviations should have the expanded word with the corresponding ca= pital letter. > GMPLS is not initially expanded in the Abstract section. > s/RB identifier./RB identifiers./ Thanks! Kathleen >=20 > Shawn. > -- >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Wed Mar 4 12:36: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 A9C241A88A8 for ; Wed, 4 Mar 2015 12:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 8HT1qgI1DJKZ for ; Wed, 4 Mar 2015 12:36:11 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 C500A1ACE8D for ; Wed, 4 Mar 2015 12:36:09 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t24Ka2Bf011361 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Mar 2015 15:36:05 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t24Ka2Bf011361 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1425501365; bh=BI3sLfk/s9ZWXMfyniNXF5KJ6mU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=OJUyp9g7i1/8ujOXV29iX9neoUdVwpPzrk+pxAUrQxzHwVK4egn3h0kbKB1dVSHkU A6HKInbdftMgN4U8Dsf/wwuZ4ioeUnxD4Nl5mqDGhUCFBwZxvB7y4P7D5KHQPMbV7b a2R0+vBUDVhTEGaqB28bFoF8h3CiPkBw0dwXul4M= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t24Ka2Bf011361 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 4 Mar 2015 15:35:25 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t24KZmr8001370 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 15:35:49 -0500 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub04.corp.emc.com (10.254.141.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 4 Mar 2015 15:35:48 -0500 Received: from MX103CL02.corp.emc.com ([169.254.6.139]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0224.002; Wed, 4 Mar 2015 15:35:48 -0500 From: "Moriarty, Kathleen" To: Chris Inacio Thread-Topic: [secdir] Assignments Thread-Index: AQHQVPjzZLrAXbzJSUeutLWdcIDO750KdXmAgAJWLEc= Date: Wed, 4 Mar 2015 20:35:47 +0000 Message-ID: References: <21748.31172.981305.579910@fireball.kivinen.iki.fi>, <310E5277-9CA0-4130-BE3B-FD9CC20F7ABD@cert.org> In-Reply-To: <310E5277-9CA0-4130-BE3B-FD9CC20F7ABD@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "secdir-secretary@mit.edu" , "secdir@ietf.org" Subject: Re: [secdir] Assignments 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, 04 Mar 2015 20:36:12 -0000 Thank you, Chris! As much as you can do is appreciated. Best regards, Kathleen Sent from my iPhone > On Mar 2, 2015, at 10:55 PM, "Chris Inacio" wrote: >=20 > Kathleen, Stephen, >=20 > Just a heads up that I will try, but a 120 page draft on a protocol I=92m= not familiar with yet will be a challenge to get fully reviewed in 10 days= . >=20 > -- > Chris Inacio > inacio@cert.org >=20 >=20 >=20 >> On Mar 2, 2015, at 9:55 AM, Tero Kivinen wrote: >>=20 >> Because of my vacation I was not able to do assignments for last few >> weeks, so some of these reviews have VERY short time to be completed. >> I hope people are still able to do the reviews even when the telechat >> is already in this week. >>=20 >> Review instructions and related resources are at: >> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>=20 >> Simon Josefsson is next in the rotation. >>=20 >> For telechat 2015-03-05 >>=20 >> Alan DeKok T 2015-02-18 draft-ietf-teas-rsvp-te-li-lb-04 >> Donald Eastlake T 2015-02-20 draft-ietf-6tisch-tsch-05 >> Olafur Gudmundsson T 2015-03-05 draft-ietf-bfcpbis-rfc4582bis-13 >> Phillip Hallam-Baker T 2015-03-03 draft-ietf-ccamp-gmpls-general-const= raints-ospf-te-09 >> Steve Hanna T 2015-03-03 draft-ietf-stox-chat-10 >> David Harrington T 2015-03-03 draft-ietf-mpls-lsp-ping-registry-02 >> Jeffrey Hutzelman T 2015-03-03 draft-ietf-stox-im-12 >> Leif Johansson T 2015-03-03 draft-ietf-stox-groupchat-10 >> Carl Wallace T 2015-02-10 draft-ietf-netext-ani-location-08 >>=20 >>=20 >> For telechat 2015-03-12 >>=20 >> Dave Cridland T 2015-02-18 draft-ietf-teas-lsp-attribute-ro-03 >> Dan Harkins T 2015-03-04 draft-ietf-dhc-dhcpv6-stateful-issue= s-11 >> Paul Hoffman T 2015-03-12 draft-ietf-idr-error-handling-18 >> Chris Inacio T 2015-03-10 draft-ietf-pim-rfc4601bis-04 >> Melinda Shore T 2015-02-24 draft-faltstrom-uri-11 >>=20 >> Last calls and special requests: >>=20 >> Dorothy Gellert 2015-02-23 draft-ietf-teas-mpls-tp-rsvpte-ext-a= ssociated-lsp-06 >> Tobias Gondrom 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-04 >> Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluatio= n-14 >> Sam Hartman 2015-03-11 draft-ietf-netconf-rfc5539bis-09 >> Jeffrey Hutzelman 2015-01-07 draft-ietf-dnssd-requirements-04 >> Radia Perlman R2015-03-09 draft-ietf-lmap-framework-11 >> Zach Shelby 2014-06-06 draft-housley-implementer-obligation= s-02 >> Sam Weiler 2015-02-16 draft-ietf-6man-resilient-rs-04 >> --=20 >> kivinen@iki.fi >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Wed Mar 4 14:11:58 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 37DFD1A879F; Wed, 4 Mar 2015 11:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 eyWnr3JuF-QS; Wed, 4 Mar 2015 11:42:45 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF241A8727; Wed, 4 Mar 2015 11:42:45 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C95ADC20C; Wed, 4 Mar 2015 14:42:44 -0500 (EST) Date: Wed, 4 Mar 2015 14:42:44 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20150304194244.GB9142@pfrc> References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Wed, 04 Mar 2015 14:11:57 -0800 Cc: i2rs@ietf.org, secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 04 Mar 2015 19:42:46 -0000 To expand on some of Sue's details in-line: On Tue, Mar 03, 2015 at 05:08:05PM -0500, Susan Hares wrote: > Thank you for your clear question - let me try to unpack and answer your > question. I really appreciate your aid in working through these cases. > > > The asynchronous models we've discussed are: > 1) polling based - I2RS client queries at a set of agents to receive status > information An example of this is the GET operation in NETCONF or RESTCONF. > 2) call-back based - the I2RS Client performs an action (adds an interface) > and the I2RS agent returns a response after the sequence is done. An example of this is creating a subscription against interface state, then taking an action (edit-config, RPC) that adds that interface. > 3) pub/sub based - meaning the I2RS clients sign up to receive publications > of results. E.g. netconf notifications > 4) atomic based - a sequence of commands that are done and then returned > with a call-back. > (if you think I've missed one, please let me know). Most of our cases fit this and are aligned with RESTCONF. > > IHMO the use of a checkpoint in each of the cases is the following. > 1) polling > The checkpoint (or revision counter) would be used to indicate if something > else had written or change the portion of the tree after the polling began. > This checkpoint can be for the whole tree or a model. The keeping of a > checkpoint per item within a model may be prohibited. This checkpoint detail is something that we will likely need to raise to the netconf group as a component to assist in I2RS scenarios. Here's a high level description of how it might work. There is a presumption that it may be possible for the I2RS agent to restart. Given that a number of I2RS operations are likely to be built using multiple interactions with the agent, it's necessary to understand what state the agent may be in with regard to last-reset. A simple but unscalable way to implement this is to preceed each operation with a get/get-config to verify the state of the system prior to sending in the next I2RS operation. What is likely more stable is simply knowing whether the system is in the same state as when you last interacted with it. A version numbering system of some sort, whether system-wide or potentially as part of some models (perhaps even just I2RS models) would be sufficient to provide such a checkpoint. An example of the problem space this would address presuming three operations must be completed to accomplish a given I2RS goal, "A B C". If the agent crashes after B has been done, C may either complete with no errors, or may fail before the setup state for A and B are no longer in the system. An analogous mechanism in SNMP to address such issues are discontinuity objects. -- Jeff From nobody Wed Mar 4 14:12: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 AB5FF1ACE73; Wed, 4 Mar 2015 12:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 VluP8SX9BdHE; Wed, 4 Mar 2015 12:29:17 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CE0A21ACE71; Wed, 4 Mar 2015 12:29:17 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 78853C1B5; Wed, 4 Mar 2015 15:29:17 -0500 (EST) Date: Wed, 4 Mar 2015 15:29:17 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20150304202917.GC9142@pfrc> References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Wed, 04 Mar 2015 14:11:57 -0800 Cc: 'Jeffrey Haas' , i2rs@ietf.org, secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 04 Mar 2015 20:29:18 -0000 On Mon, Mar 02, 2015 at 05:27:17PM -0500, Susan Hares wrote: > 1) The protocol can launch operations and then check back later whether > they successfully completed. > > 2) If you want to execute a second operation only if a first succeeds > (or to guarantee the order in which they execute), you need to at some point > wait for operations to complete. > > 3) There is also substantial overhead in supporting asynchronous > operation in that all transactions need labels so that they can be queried? > > > > Question 1: Do we believe that netconf or restconf augmented by the > traceability requirements and the pub/sub requirements provides this > support? >From memory, NETCONF will support async operations. RESTCONF will support asynchronous operations for Yang RPC. > Question 2: Do we need a checkpoint (monotonically incrementing counter to > accomplish #2)? I articulated a case for it in a later message. It's really there to handle the exception case of a restart by the I2RS agent. Such an item would require eventual protocol support, but should not be a factor that prevents work from advancing on I2RS applications in the short term. > Question 3 Context: > > The security directorate reviewer of the I2RS architecture stated: > > " A conceptually simpler strategy [than the asynchronous strategy] is to say > that since a client can make multiple parallel connections to an agent that > in cases where a client wants asynchronous operation he opens multiple > connections and launches one asynchronous operation on each. The cost is > that is has lower performance in cases where there are large numbers of > parallel operations tying up lots of connection state." > > > > In my understanding RESTCONF provides one operations per session. > > > > Question 3: If the I2RS client requires a tradeoff where that restricts the > space requirements for parallel sessions, is the space requirement for > output only (so that pub/sub requirements) are sufficient. Or should this > tradeoff be considered in the I2RS protocol requirements. This is likely to be a multi-variable equation. While the system may have limits on the number of sessions it is willing to support, the system may also have resource contention for the multiple operations that have been queued by the various sessions. The ability to pipeline work and the mechanisms to best optimize that will likely be somewhat implementation specific. In terms of protocol, I don't think there's a specific tradeoff. -- Jeff From nobody Wed Mar 4 14:12:01 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 13FAE1ACE9C; Wed, 4 Mar 2015 12:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 au3_g_YEKXFE; Wed, 4 Mar 2015 12:38:13 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2B27B1ACE8D; Wed, 4 Mar 2015 12:38:13 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E1D6EC1B5; Wed, 4 Mar 2015 15:38:12 -0500 (EST) Date: Wed, 4 Mar 2015 15:38:12 -0500 From: Jeffrey Haas To: Jeffrey Haas Message-ID: <20150304203812.GD9142@pfrc> References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <20150304202917.GC9142@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150304202917.GC9142@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Wed, 04 Mar 2015 14:11:57 -0800 Cc: i2rs@ietf.org, Susan Hares , secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 04 Mar 2015 20:38:17 -0000 On Wed, Mar 04, 2015 at 03:29:17PM -0500, Jeffrey Haas wrote: > From memory, NETCONF will support async operations. RESTCONF will support > asynchronous operations for Yang RPC. Kent Watsen corrects me in that netconf (section 4.5) current requires pipelining RPC operations. Things may still be submitted asynchronously, but completion order is not independent. -- Jeff From nobody Wed Mar 4 14:15:48 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 2C20A1A892A; Wed, 4 Mar 2015 14:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 kfcrHbuml_ZA; Wed, 4 Mar 2015 14:15:46 -0800 (PST) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045561A1BCF; Wed, 4 Mar 2015 14:15:46 -0800 (PST) Received: by oiba3 with SMTP id a3so8421668oib.3; Wed, 04 Mar 2015 14:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=QJVB9abphQGp2gX/Hsy1l6kJ2kwPevw4WxxmK0fYN4s=; b=QjADkMpwaQlTHy9cIiWG1rCLDl44H4J/TqlM2MC0wdayLdD6byGEkgXNb8ks9RwFBw ckQPYMbETs6dfJkfIIBAUEm1jSOhey/F5jFtV3V7dP1+DcjRg4voYhwHujdAJ7g49vne wtF6XRL4qr93RkRGhOK91/pKqcffj5SlPQXmZ8821n1B+ArLcA8QQujigHooUhuBwT07 HYB3zSnk+hWcv07Pw+QDAGIMpnnC0AFil3gQ9HA7Pvo1ZJEPsWm6qsgPGNbYGIMrUZW3 2YzNBlvTHDaFHBJvx7c2CMFvEa34JM8IznW4C0reuGAQwG/3rC11AW8WQIj2I9xpF1rE zG0A== X-Received: by 10.202.219.215 with SMTP id s206mr4427444oig.114.1425507300485; Wed, 04 Mar 2015 14:15:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.155.134 with HTTP; Wed, 4 Mar 2015 14:14:40 -0800 (PST) From: Donald Eastlake Date: Wed, 4 Mar 2015 17:14:40 -0500 Message-ID: To: "iesg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-trill-aa-multi-attach.all@tools.ietf.org, "secdir@ietf.org" Subject: [secdir] SECDIR review of draft-ietf-6tisch-tsch-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 22:15:47 -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. Document editors and WG chairs should treat these comments just like any other last call comments. My apologies for getting this review in late. This draft is an Informational description of the environment, problem statement, and initial goals for the Time Slotted Channel Hopping (TSCH) MAC protocol in the context of low power and lossy networks. The Security Considerations section basically defers security to more detailed specification documents, which I think is reasonable for an Informational document like this draft. It does point out that security is a requirement in joining the network and in data transfer and control messages. I believe this draft is OK from a security point of view. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed Mar 4 15:09:55 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 267091A0016; Wed, 4 Mar 2015 15:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 LLzrzq8Ps-ap; Wed, 4 Mar 2015 15:09:49 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BA01A000E; Wed, 4 Mar 2015 15:09:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1FB1CF9B; Thu, 5 Mar 2015 00:09:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GGhQy-i2gUxQ; Thu, 5 Mar 2015 00:09:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Mar 2015 00:09:46 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53C2C2003A; Thu, 5 Mar 2015 00:09:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fotb3XaTAPCE; Thu, 5 Mar 2015 00:09:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4666020039; Thu, 5 Mar 2015 00:09:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 24F3C325BF2D; Thu, 5 Mar 2015 00:09:41 +0100 (CET) Date: Thu, 5 Mar 2015 00:09:40 +0100 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20150304230940.GA68185@elstar.local> Mail-Followup-To: Jeffrey Haas , Susan Hares , i2rs@ietf.org, 'Melinda Shore' , secdir@ietf.org References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> <20150304194244.GB9142@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150304194244.GB9142@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, Susan Hares , secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 23:09:52 -0000 On Wed, Mar 04, 2015 at 02:42:44PM -0500, Jeffrey Haas wrote: > > There is a presumption that it may be possible for the I2RS agent to > restart. Given that a number of I2RS operations are likely to be built > using multiple interactions with the agent, it's necessary to understand > what state the agent may be in with regard to last-reset. A simple but > unscalable way to implement this is to preceed each operation with a > get/get-config to verify the state of the system prior to sending in the > next I2RS operation. > If this is a problem (which I am not sure), then send a get/get-config before each edit operation won't buy you much since the agent can still restart inbetween. > What is likely more stable is simply knowing whether > the system is in the same state as when you last interacted with it. > > A version numbering system of some sort, whether system-wide or potentially > as part of some models (perhaps even just I2RS models) would be sufficient > to provide such a checkpoint. > > An example of the problem space this would address presuming three > operations must be completed to accomplish a given I2RS goal, "A B C". > If the agent crashes after B has been done, C may either complete with no > errors, or may fail before the setup state for A and B are no longer in the > system. The simple solution is to make "A B C" one atomic edit. > An analogous mechanism in SNMP to address such issues are discontinuity > objects. No, not really. Discontinuity objects help with monitoring, not so much with sets. SNMP folks invented TestAndIncr (RFC 2579), which is used to implement so called spin-lock objects. While this can be made to work, I am not sure I would recommend this approach. While this method allows to detect that edits were conflicting, it makes the clients responsible to clean up the mess. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 5 00:18:11 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 5F4741B2A54; Thu, 5 Mar 2015 00:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 LIv0PoNdQwAG; Thu, 5 Mar 2015 00:18:07 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895D81B2A52; Thu, 5 Mar 2015 00:18:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3076F93B; Thu, 5 Mar 2015 09:18:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HQyU25qMWaQr; Thu, 5 Mar 2015 09:17:47 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Mar 2015 09:18:05 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FB692003D; Thu, 5 Mar 2015 09:18:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Qbl_mYf7vwLR; Thu, 5 Mar 2015 09:18:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1FD620036; Thu, 5 Mar 2015 09:18:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC9A3325C99B; Thu, 5 Mar 2015 09:18:02 +0100 (CET) Date: Thu, 5 Mar 2015 09:18:02 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150305081801.GA68988@elstar.local> Mail-Followup-To: Andy Bierman , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" , Melinda Shore , secdir@ietf.org References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> <20150304194244.GB9142@pfrc> <20150304230940.GA68185@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , Susan Hares , secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 08:18:09 -0000 On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote: > On Wed, Mar 4, 2015 at 3:09 PM, Juergen Schoenwaelder > wrote: > > On Wed, Mar 04, 2015 at 02:42:44PM -0500, Jeffrey Haas wrote: > >> > >> There is a presumption that it may be possible for the I2RS agent to > >> restart. Given that a number of I2RS operations are likely to be built > >> using multiple interactions with the agent, it's necessary to understand > >> what state the agent may be in with regard to last-reset. A simple but > >> unscalable way to implement this is to preceed each operation with a > >> get/get-config to verify the state of the system prior to sending in the > >> next I2RS operation. > >> > > > > If this is a problem (which I am not sure), then send a get/get-config > > before each edit operation won't buy you much since the agent can > > still restart inbetween. > > > >> What is likely more stable is simply knowing whether > >> the system is in the same state as when you last interacted with it. > >> > >> A version numbering system of some sort, whether system-wide or potentially > >> as part of some models (perhaps even just I2RS models) would be sufficient > >> to provide such a checkpoint. > >> > >> An example of the problem space this would address presuming three > >> operations must be completed to accomplish a given I2RS goal, "A B C". > >> If the agent crashes after B has been done, C may either complete with no > >> errors, or may fail before the setup state for A and B are no longer in the > >> system. > > > > The simple solution is to make "A B C" one atomic edit. > > > > > We use entity tags and If-Match in RESTCONF so the client can > be sure it is editing the correct version of the resource instance. > This works nicely for persistent configuration, especially if > the server can reboot with the same config ETags. > > If-Match will cause the edit to fail if the server reboots and the > I2RS state is gone. > The client will get a 412 Precondition Failed response and know it might have to > start over. > > RESTCONF only requires the server to maintain an ETag for the config root. > Finer granularity (e.g., the parent resource has an ETag) is probably needed > to support multiple concurrent edits. > Thanks, this all makes sense. So there is a viable mechanism to create a sequence of linked edits. The main trade-off, however, between a single atomic edit and a sequence of linked edits is who is taking the pain to cleanup the mess if things fail in the middle. If you write a client, you love the server to do it. If you write a server, you love the client to do it. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 5 00:36: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 6A5F51B2A89; Thu, 5 Mar 2015 00:36:14 -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 finkS4vQnMcp; Thu, 5 Mar 2015 00:36:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAE81B2A30; Thu, 5 Mar 2015 00:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2546; q=dns/txt; s=iport; t=1425544571; x=1426754171; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u0B5ETFcq/TdzztdbAPNpLAKTeCo5d+d0wXoLKgmGNo=; b=jF48Vmg8VjiMF/1wVdx1HISKeJIJ7DnsYcTMvcBNczsLKrpmEjtcHspr CR/oMCIh73Ft4jxPl5zTH8sUMkn8Lidn6Yk12eYMJatC5qz+btpq6x5MF TJu6uvur5WHTbbQdmCSvUkE4q5bJdUtyrbgmN/8UwYush0VmBl+7hrBqv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BBCQCoFPhU/4wNJK1agwJSTgwEgwe7aIgiAhyBDU0BAQEBAQF8hA8BAQEDASMRRQULAgEIGAICJgICAjAVEAIEDgWIJwi9CJp4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXOEOzMHgmgvgRQBBJAFiU0Bk2sjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,345,1422921600"; d="scan'208";a="397953307" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 05 Mar 2015 08:36:10 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t258a9bp001508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 08:36:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 02:36:09 -0600 From: "Francois Le Faucheur (flefauch)" To: "Klaas Wierenga (kwiereng)" Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQVmVv5C9SG+zPj0yqYbUG8Io8tp0MiTEAgAFtdQA= Date: Thu, 5 Mar 2015 08:36:08 +0000 Message-ID: References: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> <57CC830A-5092-4BA3-9628-90B148951A16@cisco.com> <39043BA8-EE63-4B8B-9257-0660429F0897@cisco.com> In-Reply-To: <39043BA8-EE63-4B8B-9257-0660429F0897@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.202] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-logging.all@tools.ietf.org" , "Francois Le Faucheur \(flefauch\)" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 08:36:14 -0000 SGkgS2xhYXMsDQoNCj4gT24gNCBNYXIgMjAxNSwgYXQgMTE6NDgsIEtsYWFzIFdpZXJlbmdhIChr d2llcmVuZykgPGt3aWVyZW5nQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPj4+IA0KPj4+ICogUGFy YWdyYXBoIDMuMiAgQ0ROSSBMb2dnaW5nIEZpbGUgU3RydWN0dXJlDQo+Pj4gDQo+Pj4gWW91IHN0 YXRlIHRoYXQgeW91IGNob3NlIGEgZm9ybWF0IGFzIGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBX M0MgRUxGIEZvcm1hdC4gSeKAmWQgbGlrZSB0byBzZWUgYSBzaG9ydCBleHBsYW5hdGlvbiB3aHkg eW91IGNhbiBub3QgdXNlIHRoYXQgZm9ybWF0LCBhbmQgd2hldGhlciBpdCB3b3VsZCBiZSBhbiBv cHRpb24gdG8gZXh0ZW5kIHRoYXQgZm9ybWF0IHJhdGhlciB0aGFuIGRlZmluaW5nIGEgbmV3IGZv cm1hdCB0aGF0IGlzIHNsaWdodGx5IGRpZmZlcmVudCBidXQgaXMgZXNzZW50aWFsbHkgYSBmb3Jt IGFuZCBjb3VsZCBvdmVyIHRpbWUgYmUgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQuDQo+PiANCj4+ IFRoZSBXM0MgRUxGIHNwZWNpZmljYXRpb24sIHdoaWxlIGNvbW1vbmx5IHVzZWQsIGlzIHNvbWV3 aGF0IHVuZGVyc3BlY2lmaWVkIGFuZCBvbmx5IGEgZHJhZnQgZG9jdW1lbnQuIFRoZSBkb2N1bWVu dCBzYXlzOg0KPj4g4oCcDQo+PiBUaGlzIGlzIGEgVzNDIFdvcmtpbmcgRHJhZnQgZm9yIHJldmll dyBieSBXM0MgbWVtYmVycyBhbmQgb3RoZXIgaW50ZXJlc3RlZCBwYXJ0aWVzLiBJdCBpcyBhIGRy YWZ0IGRvY3VtZW50IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug VzNDIFdvcmtpbmcgRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g YXMgb3RoZXIgdGhhbiAid29yayBpbiBwcm9ncmVzc+KAnS4NCj4+IOKAnA0KPj4gU28gaXQgZG9l cyBub3Qgc2VlbSBhcHByb3ByaWF0ZSB0byBzaW1wbHkgcmV1c2UgdGhhdCBzcGVjLCBvciBldmVu IHRvIHVzZSBpdCBhcyBhIHN0YWJsZSBiYXNlIHRvIGV4dGVuZCBmcm9tLg0KPj4gDQo+PiANCj4+ IEJlc2lkZXMsIHdl4oCZdmUgcmVhbGx5IHN0YXJ0ZWQgZnJvbSBFTEYgYW5kIGRpdmVyZ2VkIHdo ZXJlIG5lY2Vzc2FyeSBvciB1c2VmdWwuDQo+PiBTZXZlcmFsIG9mIHRoZSBkaXJlY3RpdmVzIHdl IG5lZWRlZCBkbyBub3QgaGF2ZSBhbnkgZXF1aXZhbGVudCBpbiBFTEYuIFF1aXRlIGEgZmV3IGZp ZWxkcyB3ZSBuZWVkZWQgZG8gbm90IGhhdmUgYW4gZXF1aXZhbGVudCBpbiBFTEYsIGFuZC9vciBk byBub3QgaGF2ZSBhIHRvdGFsbHkgdW5hbWJpZ291cyBkZXNjcmlwdGlvbi4NCj4+IEFsc28gd2Ug bmVlZGVkIHRvIGJlIGFibGUgdG8gY2FycnkgbG9ncyBmb3Igbm9uLUhUVFAgcHJvdG9jb2xzLg0K PiANCj4gb2ssIHRoYXQgaXMgYSBjb252aW5jaW5nIGFyZ3VtZW50LiBIb3cgYWJvdXQgaW5jbHVk aW5nIGEgc3RhdGVtZW50IHRvIHRoYXQgZXh0ZW50LCBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVz IG9mOiDigJx3ZSB0b29rIEVMRiBhcyBhIHN0YXJ0aW5nIHBvaW50IGFuZCByZXVzZWQgd2hlcmUg cG9zc2libGUgYW5kIGV4cGFuZGVkIHdoZW4gbmVjZXNzYXJ54oCdDQoNClNvdW5kcyBnb29kLiBJ 4oCZdmUgYWRkZWQ6DQoiDQpUaGUgVzNDIEV4dGVuZGVkIExvZyBGaWxlIEZvcm1hdCB3YXMgdXNl ZCBhcyBhIHN0YXJ0aW5nIHBvaW50LCByZXVzZWQgd2hlcmUgcG9zc2libGUgYW5kIGV4cGFuZGVk IHdoZW4gbmVjZXNzYXJ5Lg0KIg0KDQoNCkkgdGhpbmsgd2UgaGF2ZSBjb252ZXJnZWQgb24gZXZl cnl0aGluZyBlbHNlLg0KDQpDaGVlcnMNCg0KRnJhbmNvaXM= From nobody Thu Mar 5 01:45: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 3487C1A0469 for ; Thu, 5 Mar 2015 01:45:24 -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 TVt7NA0NWySJ for ; Thu, 5 Mar 2015 01:45:22 -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 7DE771A03FF for ; Thu, 5 Mar 2015 01:45:22 -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 t259jJSx004018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Mar 2015 11:45:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t259jI0N014478; Thu, 5 Mar 2015 11:45:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21752.9646.432789.569562@fireball.kivinen.iki.fi> Date: Thu, 5 Mar 2015 11:45:18 +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, 05 Mar 2015 09:45:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Warren Kumari is next in the rotation. For telechat 2015-03-05 Reviewer LC end Draft Alan DeKok T 2015-02-18 draft-ietf-teas-rsvp-te-li-lb-05 Olafur Gudmundsson T 2015-03-05 draft-ietf-bfcpbis-rfc4582bis-13 Steve Hanna T 2015-03-03 draft-ietf-stox-chat-10 David Harrington T 2015-03-03 draft-ietf-mpls-lsp-ping-registry-02 Jeffrey Hutzelman T 2015-03-03 draft-ietf-stox-im-12 Carl Wallace T 2015-02-10 draft-ietf-netext-ani-location-08 For telechat 2015-03-12 Dave Cridland T 2015-02-18 draft-ietf-teas-lsp-attribute-ro-03 Dan Harkins T 2015-03-04 draft-ietf-dhc-dhcpv6-stateful-issues-11 Jeffrey Hutzelman T 2015-01-07 draft-ietf-dnssd-requirements-05 Chris Inacio T 2015-03-10 draft-ietf-pim-rfc4601bis-04 Stephen Kent T 2015-02-23 draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 Melinda Shore T 2015-02-24 draft-faltstrom-uri-12 Last calls and special requests: Tobias Gondrom 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-04 Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Sam Hartman 2015-03-11 draft-ietf-netconf-rfc5539bis-09 Simon Josefsson 2015-03-18 draft-ietf-bess-mvpn-bidir-03 Benjamin Kaduk 2015-03-18 draft-ietf-ccamp-wson-signaling-09 Charlie Kaufman 2015-03-16 draft-ietf-oauth-dyn-reg-24 Scott Kelly 2015-03-16 draft-ietf-sacm-use-cases-08 Tero Kivinen 2015-03-17 draft-ietf-tram-stun-origin-05 Radia Perlman R2015-03-09 draft-ietf-lmap-framework-11 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Sam Weiler 2015-02-16 draft-ietf-6man-resilient-rs-04 -- kivinen@iki.fi From nobody Thu Mar 5 04:26: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 32D2B1A014D for ; Wed, 4 Mar 2015 15:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 jVW64RDtAjwx for ; Wed, 4 Mar 2015 15:57:52 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297F61A00C3 for ; Wed, 4 Mar 2015 15:57:52 -0800 (PST) Received: by lamq1 with SMTP id q1so24969513lam.0 for ; Wed, 04 Mar 2015 15:57:50 -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:content-type; bh=5pw5MJ3OXKPpwcJM3q8MOKOwyFvR7B4r8Cvo6XdeSNI=; b=POeyKc4Dx5UWhn3wFRY35me45CIWZQug7Y66WljQd0LOCf5cpyF9oReFbdb4nMfV3j 77i1+y0JiJVswAm/OWix66f5My3mG3Ag24uam6MiNkME030HJjRSXLFNdidbYpNnpQAS I39cqbgHovQa/jU7wVeKhbPdA5TF9Nam7ZaYYWJpLHTYgnILxNpUvE2Iv1y2gDvAYrfR qcOOjCL12SuqPYjSYnHqorqWWw8/BnlZaynMBF2YuqtfYsXis1w2ALkEfMn+DzbjxTgt d7J3Fm3dYYw3Bd4xuxJJZ2/9qGmIE2Sbr4ALTSOpxDIWupdfO6bW13SlRDD7cfQ0MGDs 7Pbw== X-Gm-Message-State: ALoCoQnJ3xGaeXedkZ6p02zWtJE96PyR2iWxJIRtazIBOcGhTQLQJ9y3Iw7MkDxm2tmQBeGiVXpR MIME-Version: 1.0 X-Received: by 10.152.23.233 with SMTP id p9mr5453807laf.123.1425513470576; Wed, 04 Mar 2015 15:57:50 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 4 Mar 2015 15:57:50 -0800 (PST) In-Reply-To: <20150304230940.GA68185@elstar.local> References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> <20150304194244.GB9142@pfrc> <20150304230940.GA68185@elstar.local> Date: Wed, 4 Mar 2015 15:57:50 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" , Melinda Shore , secdir@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 04:25:58 -0800 Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 04 Mar 2015 23:57:54 -0000 On Wed, Mar 4, 2015 at 3:09 PM, Juergen Schoenwaelder wrote: > On Wed, Mar 04, 2015 at 02:42:44PM -0500, Jeffrey Haas wrote: >> >> There is a presumption that it may be possible for the I2RS agent to >> restart. Given that a number of I2RS operations are likely to be built >> using multiple interactions with the agent, it's necessary to understand >> what state the agent may be in with regard to last-reset. A simple but >> unscalable way to implement this is to preceed each operation with a >> get/get-config to verify the state of the system prior to sending in the >> next I2RS operation. >> > > If this is a problem (which I am not sure), then send a get/get-config > before each edit operation won't buy you much since the agent can > still restart inbetween. > >> What is likely more stable is simply knowing whether >> the system is in the same state as when you last interacted with it. >> >> A version numbering system of some sort, whether system-wide or potentially >> as part of some models (perhaps even just I2RS models) would be sufficient >> to provide such a checkpoint. >> >> An example of the problem space this would address presuming three >> operations must be completed to accomplish a given I2RS goal, "A B C". >> If the agent crashes after B has been done, C may either complete with no >> errors, or may fail before the setup state for A and B are no longer in the >> system. > > The simple solution is to make "A B C" one atomic edit. > We use entity tags and If-Match in RESTCONF so the client can be sure it is editing the correct version of the resource instance. This works nicely for persistent configuration, especially if the server can reboot with the same config ETags. If-Match will cause the edit to fail if the server reboots and the I2RS state is gone. The client will get a 412 Precondition Failed response and know it might have to start over. RESTCONF only requires the server to maintain an ETag for the config root. Finer granularity (e.g., the parent resource has an ETag) is probably needed to support multiple concurrent edits. >> An analogous mechanism in SNMP to address such issues are discontinuity >> objects. > > No, not really. Discontinuity objects help with monitoring, not so > much with sets. SNMP folks invented TestAndIncr (RFC 2579), which is > used to implement so called spin-lock objects. While this can be made > to work, I am not sure I would recommend this approach. While this > method allows to detect that edits were conflicting, it makes the > clients responsible to clean up the mess. > > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Mar 5 04: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 30C891A0387; Thu, 5 Mar 2015 04:56:10 -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 cZD9q_mlbwes; Thu, 5 Mar 2015 04:56:08 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C46B1A01A9; Thu, 5 Mar 2015 04:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2169; q=dns/txt; s=iport; t=1425560169; x=1426769769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mfa1hMLx8GHkiAX3cAFNx+NX+MHiBISLHwjBFOa0HZk=; b=QBFNcdRHMByvsx3r/342wg6bYUKuTbKWaTq1/8q6PgkX+pvLUwch8NJg ddUgMF8lkRjbofZ5BH5DeAmjeKQAYiK2WoRYnkLPSve54AQyI7r/s+ylX 62RMVBuIJqSgGG+yEyOsVDzkXHaF0grESjGNTCe1lqor4sBCBrWOT+NML 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DMBwDCUfhU/4YNJK1agwVSTgy+fIgiAoE2TQEBAQEBAXyEDwEBBAF5BQsCAQgYLjIlAgQOBYgnCNd9AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sUhDszB4MXgRQBBJAFiU2TbCODbm+CQwEBAQ X-IronPort-AV: E=Sophos;i="5.11,346,1422921600"; d="scan'208";a="398006570" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP; 05 Mar 2015 12:56:08 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t25Cu6u9001364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 12:56:07 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.223]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 06:56:06 -0600 From: "Klaas Wierenga (kwiereng)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: review of draft-ietf-cdni-logging.15 Thread-Index: AQHQR6bsatwFQJOdLkuG1v9BlCIAFZ0MoCWAgAAGh4CAAW11AP//5A1X Date: Thu, 5 Mar 2015 12:56:06 +0000 Message-ID: <0B18D07F-126D-40FA-8C51-E932BAA74DCF@cisco.com> References: <493249E6-FD3B-46F3-AA3E-79ED26B594E1@cisco.com> <57CC830A-5092-4BA3-9628-90B148951A16@cisco.com> <39043BA8-EE63-4B8B-9257-0660429F0897@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-logging.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-ietf-cdni-logging.15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:56:10 -0000 I am happy with all of the proposed changes now, great job! Sent from my iPhone > On 05 Mar 2015, at 09:36, Francois Le Faucheur (flefauch) wrote: >=20 > Hi Klaas, >=20 >> On 4 Mar 2015, at 11:48, Klaas Wierenga (kwiereng) = wrote: >>=20 >>>>=20 >>>> * Paragraph 3.2 CDNI Logging File Structure >>>>=20 >>>> You state that you chose a format as close as possible to the W3C ELF = Format. I=92d like to see a short explanation why you can not use that form= at, and whether it would be an option to extend that format rather than def= ining a new format that is slightly different but is essentially a form and= could over time be significantly different. >>>=20 >>> The W3C ELF specification, while commonly used, is somewhat underspecif= ied and only a draft document. The document says: >>> =93 >>> This is a W3C Working Draft for review by W3C members and other interes= ted parties. It is a draft document and may be updated, replaced or obsolet= ed by other documents at any time. It is inappropriate to use W3C Working D= rafts as reference material or to cite them as other than "work in progress= =94. >>> =93 >>> So it does not seem appropriate to simply reuse that spec, or even to u= se it as a stable base to extend from. >>>=20 >>>=20 >>> Besides, we=92ve really started from ELF and diverged where necessary o= r useful. >>> Several of the directives we needed do not have any equivalent in ELF. = Quite a few fields we needed do not have an equivalent in ELF, and/or do no= t have a totally unambigous description. >>> Also we needed to be able to carry logs for non-HTTP protocols. >>=20 >> ok, that is a convincing argument. How about including a statement to th= at extent, something along the lines of: =93we took ELF as a starting point= and reused where possible and expanded when necessary=94 >=20 > Sounds good. I=92ve added: > " > The W3C Extended Log File Format was used as a starting point, reused whe= re possible and expanded when necessary. > " >=20 >=20 > I think we have converged on everything else. >=20 > Cheers >=20 > Francois From nobody Fri Mar 6 00:35: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 3DB961ACD3D; Fri, 6 Mar 2015 00:35:46 -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, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 RRa1qVGehjpl; Fri, 6 Mar 2015 00:35:41 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 D08321ACD38; Fri, 6 Mar 2015 00:35:40 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8AF0543978; Fri, 6 Mar 2015 09:35:39 +0100 (CET) Message-ID: <54F966DB.8000901@restena.lu> Date: Fri, 06 Mar 2015 09:35:39 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.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: OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh" Archived-At: 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: Fri, 06 Mar 2015 08:35:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh Content-Type: multipart/mixed; boundary="------------050904090102080003050004" This is a multi-part message in MIME format. --------------050904090102080003050004 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello all, sorry for taking so long :-( > This document specifies a means to find authoritative RADIUS servers fo= r a given realm. This can be useful when authenticating/authorizing devic= es within a roaming consortium (e.g., eduroam). An authoritative RADIUS c= lient trying to authenticate/authorize a host or perform accounting for t= hat host finds a RADIUS server by querying DNS for service records define= d in this document. Once a candidate sever has been found in DNS, the que= rier initiates a RADIUS protocol to it protected by TLS, authorizes it ba= sed on information in its certificate, and then RADIUS happens in the usu= al fashion. The document is almost ready for publication, in my opinion. >=20 > There=92s not much background given, and having an overview of the solu= tion architecture in the Introduction would be useful. I.e., a descriptio= n and picture showing the actors and the communication flows between them= =2E 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 s= ervers and I thought only clients contacted servers. An overview of the a= ctors would probably have clarified that. I have added two ASCII art descriptions: how static request routing works (in an example deployment which uses top-level domain endings to partition the realm space) and one where DNS replaces these static routing rules. I hope the art and accompanying text clarifies the documen= t. > If I understand correctly how roaming consortiums currently work today,= a RADIUS client within a consortium needing to make a AAA call to a RADI= US server in another realm does not contact the server directly. Instead,= it routes the request through a hierarchy of RADIUS servers following ro= ots of trust. The trust model in this document seems to be bypass the roo= ts of trust, where the client directly contacts the server. This seems to= be discussed in the Section 6 (Privacy Considerations) discussion of =93= clearinghouses", but if the trust model is changed, this is a bigger impa= ct than privacy so ought to be discussed explicitly someplace in the docu= ment. It doesn't bypass trust; it moves trust away from static IP adress and shared secrets to a trust based on PKIX and DNS. The roots of trust still exist, they are just not RADIUS servers any more, but CAs, and they do their work out-of-band (CA issuing/revoking certs instead of a RADIUS proxy inspecting each packet and making a packet-by-packet trust decision). In other words, the RADIUS client and RADIUS server remain the same actors and they maintain their same level of trust as before. The impact on privacy is the most outstanding one, and is extensively discussed in the document. There is indeed another aspect, and that is a technical one: the hierarchy/star topology of intermediate servers can do sanitisation of packets as they pass by (typically, removing, adding, or re-writing RADIUS attributes); when these intermediates are not in place any more, a RADIUS server needs to expect more diversified packets coming in and it may need to do some sanitisation itself. A sentence to that effect is in the draft, inside privacy considerations. Maybe that's not the best place, but I do think that this beyond-privacy aspect is touched upon. I'm speaking of this sentence= : "However, there exist reasons why clearinghouses might still be used. One reason to keep a clearinghouse is to act as a gateway for multiple backends in a company; another reason may be a requirement to sanitise RADIUS datagrams (filter attributes, tag requests with new attributes, ... )." > Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the p= oint that certificate based cipher suites need to be used because there w= on=92t be any pre-distributed secret key material available. That=92s goo= d advice. I think the section should also give advice on choosing trust r= oots. 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., SubjectA= ltName). 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 cli= ent would be ill advised to trust authorization information claims in th= e hierarchy. On the other hand, if the trust roots were restricted to a s= et of highly trusted trust roots maintained by the consortium, then the a= uthorization information in the certificate would be t rustable. This should be explained. I have added new text (thanks Alan for the suggestion, I've reused a few sentences from the RADIUS/DTLS document), 2.1.1.3 now has a new last paragraph. > Section 2.2 defines the NAIRealm name as a form of otherName. This make= s sense. But there is also a paragraph discussing sRVName, which is confu= sing. I think it=92s clarifying who sRVName isn=92t applicable; it would = be good state that plainly at the beginning of the paragraph. I'm not sure I can follow you here... NAIRealm is used to verify after discovery that the target server is authorised to handle requests for the realm that was queried from DNS. The querying itself may use either NAPTR records (preferred) or SRV records (fallback). The paragraph which discusses sRVName only makes clear why verifying sRVName against an SRV doesn't buy you anything. If you find the paragraph regarding the uselessness of sRVName confusing, I can take it out, but since issue has repeatedly been asked during the lifetime of the draft, I think it is useful to keep this explanatory statement in. > Section 5 (first paragraph) makes the point that the information gotte= n from DNS can=92t be trusted. But I would suggest a slight rewording: s/= can not be trusted/is not sufficient to identify an authorized server/. I'd prefer to keep my wording, as these are two different things: With DNS (no SEC), the result O (=3DIP addresses and ports) are potentially bogus (i.e. possibly incorrect *and* the resulting TLS connection may be to an unauthorised peer). With DNSSEC, the result O is verifiably correct, but the resulting TLS connection may still be to an unauthorised server. Your rewording would suggest that DNS-no-SEC only has a shortcoming re authorisation, but it's more than that. I've just issued rev -13 with all the above-mentioned changes. Please consult the diff at https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-rade= xt-dynamic-discovery-13.txt and let me know if you are satisfied. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050904090102080003050004 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050904090102080003050004-- --1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU+WbbAAoJEMDeajWKOdxmgpMQAMOdgXlqzSo1NmdZefQCEhKG qmkF8aCFAZ7U+BOIAwOF2yX/5ZiuH2hXm9skrC4bXq4PZ+cYfQMcG5ciFka72Jo7 vuGoyFuU/bQerSSKvTjmUVIZK9c4Cc50C3vFzG9n9HE/anV0gM5ExfFpu0ZDJapi LKa0r2kftrnFieGj5CkD5VsOcZpaoLSH5OvYKVn7MkU0x088qPJTrBq7ogaBN7nH c7Nl+7o74MI6lPGeg43dtm3DinPGC8EWFpTbQA+V6TpfMifcO1lxbyWC0Zu/T5k4 m4SidatQJ4ZZdyJswj5AUdfhdAqUBpJnDHjWVssE4zTTdrKJoCqYyljyyS+kJvv8 kur+OK/N3svhl02PgNlwTPPVJ+QWg9kj0XumgfG2Epb8e8gRNsl7WUFxlDkk5O40 19Ch7ZEEQ9zZ7eK0pg6vggeS6qWbWAn72blgENNqPgRdxOvn47HtTjx/lHRgcgKx 9EolMF7/oWoWZoO/eLruiH0G+92wvGlE/+inm0v15j5OmDbhVYE9cKGYEpXlAUxw +9RORBEAS7H5QKTms2hyIzhTk5xEwN13XNplCgokAiHf1MoyKoVb/2tTQHvflwV0 NioqTk00dOV8iY/+eMKTA8Q59ge21Dn8gP5xB72XDd9d2Ny4LCJr1TZ0tstvHy// 9FQAxXQuZgksfZSkmYTo =4TWs -----END PGP SIGNATURE----- --1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh-- From nobody Fri Mar 6 00:35:58 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 A4EED1ACD42; Fri, 6 Mar 2015 00:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 QQ8t5gfXQqwC; Fri, 6 Mar 2015 00:35:49 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (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 9C6B51ACD3E; Fri, 6 Mar 2015 00:35:49 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7954B43995; Fri, 6 Mar 2015 09:35:48 +0100 (CET) Message-ID: <54F966E4.20002@restena.lu> Date: Fri, 06 Mar 2015 09:35:48 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Brian Weis (bew)" , Alan DeKok References: <2B42564B-1BC8-437D-AACD-69785A90A795@cisco.com> In-Reply-To: <2B42564B-1BC8-437D-AACD-69785A90A795@cisco.com> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1" Archived-At: 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: Fri, 06 Mar 2015 08:35:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1 Content-Type: multipart/mixed; boundary="------------030302090704080506070500" This is a multi-part message in MIME format. --------------030302090704080506070500 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > The clarification below was very useful. Perhaps the authors will find= it valuable to include the references you mentioned, and clarify that th= ere is expected to be a limited number of trusted (preferably one) truste= d to issue certificates for the consortium use case. The NAI reference was already in the document, and I've pulled in text from the RADIUS/DTLS reference directly into the document. The text regarding the small set of CAs is now also in. Thanks, Stefan Winter >=20 > Thanks, > Brian >=20 > On Jan 4, 2015, at 8:48 PM, Alan DeKok wrot= e: >=20 >> On Dec 24, 2014, at 4:05 PM, Brian Weis wrote: >> >> I=92m not the document author, but I can help give some clarification= =2E >> >>> There=92s not much background given, and having an overview of the so= lution architecture in the Introduction would be useful. I.e., a descript= ion and picture showing the actors and the communication flows between th= em. >> >> The current roaming behaviour is discussed in the NAI document, Secti= on 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. Cl= ients 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 th= e protocol. i.e. proxies operate by consensus and habit, not by standard= behaviour. >> >> A long description of the Eduroam consortium is available as an indiv= idual draft: >> >> http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-04 >> >> However, *commercial* proxies do not operate in the eduroam model. C= ommercial proxies are largely =93star=94 configurations. An interconnect= company sits at the centre of a star. It may connect to one or more oth= er interconnect providers. Routes are largely static, and are usually up= dated by hand, after legal contracts have been exchanged. >> >> This document is standardizing provisioning of RADIUS proxying, via d= ynamic 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 se= rvers and I thought only clients contacted servers. An overview of the ac= tors would probably have clarified that. >> >> Clients are the only ones initiating requests. In some cases, the sy= stem running RADIUS can behave as a client or as a server, depending on i= t=92s needs. That makes it more complicated. >> >>> If I understand correctly how roaming consortiums currently work toda= y, a RADIUS client within a consortium needing to make a AAA call to a RA= DIUS 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 differ= ently. >> >> However, they both operate on a =93fire and forget=94 model. A RADIU= S server which wants to proxy a request somehow (magically, almost) deter= mines 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 g= ood advice. I think the section should also give advice on choosing trust= roots. This is important because the identity of the server was gotten i= n an untrusted manner (from unsecured DNS), and the certificate it presen= ts contains information used for authorization of a server (i.e., Subjec= tAltName). If a RADIUS client were to accept a certificate signed by a wi= de range of trust roots (e.g, the set of roots used by browsers, where th= e trustability of many CAs in the hierarchy is unknown) then the RADIUS c= lient would be ill advised to trust authorization information claims in = the hierarchy. >> >> Current RADIUS practice uses a limited set of CAs. Generally, only o= ne. This use-case is *very* different than that for browsers. This docu= ment 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 ove= r TLS) should probably have had such statements. RFC 7360 (RADIUS over D= TLS) 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 hig= hly trusted trust roots maintained by the consortium, then the authorizat= ion information in the certificate would be trustable. This should be exp= lained. >> >> Generally there=92s only one root CA for a consortium. I=92m not sur= e what the use-case would be for multiple root CAs. >> >> Alan DeKok. >> >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------030302090704080506070500 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------030302090704080506070500-- --sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJU+WbkAAoJEMDeajWKOdxmPdoP/j2Jgiuu39S32NSJ6iLMR5Ty yyeUoWp3TEpRCCGKsTJiVVLtZi/U0rjXSOUDpdDAKhg2o7oYLOUejQRFTOCnnYS2 NJsMHO6H6piuh+E430U+q/4/aCO1wNdlPswW0pSdqrie61w4YJ3Ft+uro8jJuzwT nX8zAayJiG2JOx582oMcRi9KWhBrLPd2F5RCLMK2JI1ffZNATrFRlipCRz4HYFy0 jAepjKwqPrfRCGgDkb5z6aC10Cixh+2YerYcYMtpK+sycKZVEFuzrmjhkzMNCHPs ItSli+LZEQmC5FQCb3eRO1yW5WxGoNVqHAq/VkwUk9F5QTYeKqLsUa/fLUyxEjpU sxzPfS18UaWIYf5xXYDBWqUyilM0NtBI1YH2jsm91pyEITz2fvMSvBz8Lbo+zP9n z8MNl1jmjrbkdPkYikJ9QSj5fwgiBqusc8Omj1ckz2IHSLFVWQPXJMc9rYYIdt1l d63PSM58qG5imrLW3/+fsUlw5qHZxButdq/rucQTA5w6hFsD6C7xcksCIlRABDVk vZcGtTHxGSxq4cnO+eRKw1rKTUtpKUd/xasB2pqB4osv5bXaF04tpHHHbMPl9w2T 11WYkHISJq0RerhWslhWJRtGZLYYz49K/IPHkq4UzdhQq089+uSmpIzX0REm+MyQ JDWCDqmQ25msra83Qk9h =Z/DJ -----END PGP SIGNATURE----- --sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1-- From nobody Fri Mar 6 08:41:10 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 C44341ACEF4; Fri, 6 Mar 2015 08:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1425659910; bh=M5QpqswS9HIo07BZR531sZyzYUzfBYCwhkrkc9VDKRw=; 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=OTugefdwdh2iqyu39huD22EeU6qx6kSCsUIqK3A8CoNQ3/NzYZEyDHyU2EvoysLqM 7bsMUFEpfMOa11r5kO54cLQ32px1QeKhM92CnQmdHDn1YIAHigi1K3CuotEX+eeRg1 BtQAIeOrm/a1/c5A2VBIX00dd30t4kfzWDFyKIVo= 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 587041A19F8; Fri, 6 Mar 2015 08:38:29 -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 OJM4QDnRvkrx; Fri, 6 Mar 2015 08:38:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7181ACEF4; Fri, 6 Mar 2015 08:38:27 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306163827.31066.20782.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 08:38:27 -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, 06 Mar 2015 08:41:09 -0800 Subject: [secdir] [new-work] WG Review: L3VPN Service Model (l3sm) 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, 06 Mar 2015 16:38:31 -0000 From: The IESG To: IETF-Announce Subject: A new IETF working group has been proposed in the Operations and Management 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-03-16. L3VPN Service Model (l3sm) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Benoit Claise Charter: The IETF and the industry in general is currently specifying a set of YANG models for network element and protocol configuration. This is an essential first step, but the end goal is full system configuration that allows the deployment of services across networks. Services are built from a combination of network element and protocol configuration, but are specified to service users in more abstract terms. The Layer Three Virtual Private Network Service Model (L3SM) working group is a short-lived WG tasked to create a YANG data model that describes a L3VPN service (a L3VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. It needs to be clearly understood that this L3VPN service model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. A separate process is responsible for mapping this service model onto the protocols and network elements depending on how the network operator chooses to realise the service. The deliverable from this working group will provide information to evaluate the set of YANG models that have already been developed or are under development, and will help identify any missing models or details. The deliverable can be viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models. It is hoped that this working group will provide evidence that such service models can be quickly constructed and agreed upon. If successful, further service models may be developed in other working groups The working group should consider draft-l3vpn-service-yang as a starting point. Milestones: Jan 2016 - L3VPN Service (YANG) Model to the IESG for publication as Proposed Standard RFC Jan 2016 - Close the working group _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Mar 6 10:09:01 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 0E63D1A1B1D for ; Fri, 6 Mar 2015 10:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 YatANgaghAhh for ; Fri, 6 Mar 2015 10:08:48 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0FA1A1AB8 for ; Fri, 6 Mar 2015 10:08:47 -0800 (PST) Received: by lamq1 with SMTP id q1so36149322lam.0 for ; Fri, 06 Mar 2015 10:08:46 -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=nh4e4MkBAarfS5f48ruhyDMEkdHN1Li/m2Wh6ty0nbo=; b=Rmf9pEHTfZmaoKxSJ9vhZM5p0LHI+pzfGtTt39W+mBHIulnUnrqkkupWiDjwyvgIS1 QSgfrk7eQoUwffMxqRkAhk06K8X2bxkRIqiV4B/1jcfedf1wCKBI4oiJrakIEbiIIK3O jg1Cc8HE4IPS8Kbdl3QEdfbjtrEXd+zErlHWR59sEdh3KRwOuKTZPZA7doPCVFKJtDNW cU43NBZjmTsHJKTbaw/1yOaQCFCKeaMp8pAr09On9dgHzEXyt2ZXJOaCFzlDTbguhkS9 ZtAIQT+lXpRyNo6K/Ie0guj932V1EKTQA2fFHCGrdwb+YzHZh4NkQEFUrYG/S9HRYMyf hSNA== X-Gm-Message-State: ALoCoQlaRRRpDHTJUTMhrnRyCLPZlsgiisBE/91J5oSJoP5izZ1IGUF4GjnrPhPVniNCR9+nt384 MIME-Version: 1.0 X-Received: by 10.112.139.136 with SMTP id qy8mr14183317lbb.38.1425665326056; Fri, 06 Mar 2015 10:08:46 -0800 (PST) Received: by 10.112.144.36 with HTTP; Fri, 6 Mar 2015 10:08:45 -0800 (PST) In-Reply-To: <20150306180434.GA10092@pfrc> References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> <20150304194244.GB9142@pfrc> <20150304230940.GA68185@elstar.local> <20150305081801.GA68988@elstar.local> <20150306180434.GA10092@pfrc> Date: Fri, 6 Mar 2015 10:08:45 -0800 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "i2rs@ietf.org" , Susan Hares , secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 06 Mar 2015 18:08:56 -0000 On Fri, Mar 6, 2015 at 10:04 AM, Jeffrey Haas wrote: > On Thu, Mar 05, 2015 at 09:18:02AM +0100, Juergen Schoenwaelder wrote: >> On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote: >> > > The simple solution is to make "A B C" one atomic edit. >> > > >> > >> > >> > We use entity tags and If-Match in RESTCONF so the client can >> > be sure it is editing the correct version of the resource instance. >> > This works nicely for persistent configuration, especially if >> > the server can reboot with the same config ETags. >> > >> > If-Match will cause the edit to fail if the server reboots and the >> > I2RS state is gone. >> > The client will get a 412 Precondition Failed response and know it might have to >> > start over. >> > >> > RESTCONF only requires the server to maintain an ETag for the config root. >> > Finer granularity (e.g., the parent resource has an ETag) is probably needed >> > to support multiple concurrent edits. >> > >> >> Thanks, this all makes sense. So there is a viable mechanism to create >> a sequence of linked edits. The main trade-off, however, between a >> single atomic edit and a sequence of linked edits is who is taking the >> pain to cleanup the mess if things fail in the middle. If you write a >> client, you love the server to do it. If you write a server, you love >> the client to do it. ;-) > > It's all pain, but some component has to deal with it. > > I'm glad that restconf seems to have this situation covered, Andy. Is there > a similar mechanism in netconf that I've missed? If so, this completely > deals with the need for i2rs to have to ask for anything new. :-) > NETCONF has no support at all for this sort of thing. > -- Jeff Andy From nobody Fri Mar 6 11:21: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 4F7191A6EEC; Fri, 6 Mar 2015 11:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 SgAWwvdHNbY0; Fri, 6 Mar 2015 11:21:47 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D382D1A3BA7; Fri, 6 Mar 2015 11:21:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9D722FC9; Fri, 6 Mar 2015 20:21:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8Jk38woZwLIV; Fri, 6 Mar 2015 20:21:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Mar 2015 20:21:43 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2943F2003C; Fri, 6 Mar 2015 20:21:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5puKc9fMJ-2h; Fri, 6 Mar 2015 20:21:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 456E220036; Fri, 6 Mar 2015 20:21:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3515232603AD; Fri, 6 Mar 2015 20:21:39 +0100 (CET) Date: Fri, 6 Mar 2015 20:21:39 +0100 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20150306192139.GA74963@elstar.local> Mail-Followup-To: Jeffrey Haas , Andy Bierman , Susan Hares , "i2rs@ietf.org" , Melinda Shore , secdir@ietf.org References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> <20150304194244.GB9142@pfrc> <20150304230940.GA68185@elstar.local> <20150305081801.GA68988@elstar.local> <20150306180434.GA10092@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150306180434.GA10092@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "i2rs@ietf.org" , Andy Bierman , Susan Hares , secdir@ietf.org Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:21:48 -0000 On Fri, Mar 06, 2015 at 01:04:34PM -0500, Jeffrey Haas wrote: > > > > Thanks, this all makes sense. So there is a viable mechanism to create > > a sequence of linked edits. The main trade-off, however, between a > > single atomic edit and a sequence of linked edits is who is taking the > > pain to cleanup the mess if things fail in the middle. If you write a > > client, you love the server to do it. If you write a server, you love > > the client to do it. ;-) > > It's all pain, but some component has to deal with it. > > I'm glad that restconf seems to have this situation covered, Andy. Is there > a similar mechanism in netconf that I've missed? If so, this completely > deals with the need for i2rs to have to ask for anything new. :-) > I think the NETCONF solution is more geared towards a single transaction solution, i.e., you can ship stuff into the candidate datastore and then commit the whole change set in one go. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 6 12:13: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 3700E1A7004 for ; Fri, 6 Mar 2015 12:13:31 -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, HTML_MESSAGE=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 NvABLJeWXbnZ for ; Fri, 6 Mar 2015 12:13:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF801A7002 for ; Fri, 6 Mar 2015 12:13:24 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:60553 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YTycN-0006Dc-4K; Fri, 06 Mar 2015 15:13:07 -0500 Message-ID: <54FA0A51.9080406@bbn.com> Date: Fri, 06 Mar 2015 15:13:05 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: secdir , zhangfei7@huawei.com, jingrq@ctbri.com.cn, rgandhi@cisco.com, lberger@labn.net, db3546@att.com, akatlas@gmail.com, adrian@olddog.co.uk, mhartley@cisco.com Content-Type: multipart/alternative; boundary="------------090900000005060101020601" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-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: Fri, 06 Mar 2015 20:13:31 -0000 This is a multi-part message in MIME format. --------------090900000005060101020601 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. As far as security is concerned, I see no problems with this document. Tracing back through the list of Security Consideration sections of cited documents in one case leads to a disappointing origin in RFC 2747. The other chain is shorter and more relevant, and it provides greater confidence that this document yields no new security concerns. This document describes extensions to RSVP to enable creating a bidirectional LSP from two p-t-p unidirectional LSPs. The security considerations section consists of just two paragraphs. The first cites the security considerations section of RFC 6780 (RSVP Association Objects) as encompassing any security issues that might arise in this context. (The assertion is that this document introduces no new signaling information, and thus no new security concerns.) The Security Considerations section of 6780 is also two paragraphs in length. That text states that no new security considerations have been introduced, because no new procedures have been defined. Hence it cites theSecurity Considerations sections of RFC 4872 and 4873. RFC 4872 cites RFC 4426 (RFC 4873 cites RFC 4872). The security considerations section of 4426 is almost a full page. It specifies security services that are required to protect the GMPLS recovery mechanisms defined in that document, but does not point to ANY security mechanisms that should be employed. RFC 4872 also establishes a few security-relevant requirements for RSVP signaling, and cites RFC 2747 as specifying the required security mechanisms. (4872 also notes that IPsec could be employed for hop-by-hop integrity and authentication, and cites RFC 3473. I note that 3473 is from 2003, and thus refers to IPsec and IKE RFCs that have been obsoleted!) RFC 2747 specifies crypto authentication mechanisms for RSVP, but dates from 2000. It anticipates that “ … the IETF will define a standard key management protocol†and thus omits specification of such in that document. (A fun walk down memory lane …) The second paragraph of the Security Considerations section of this I-D notes that additional information is conveyed in the REVERSE_LSP object, but that the information is not fundamentally different from what is carried in a bidirectional LSP message. Thus, the argument is that no fundamentally different information is being transmitted. This paragraph cites RFC 5920 (Security Framework for MPLS and GMPLS Networks) as relevant. I agree that 5920 seems to be most appropriate RFC in this context. --------------090900000005060101020601 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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.

 

As far as security is concerned, I see no problems with this document. Tracing back through the list of Security Consideration sections of cited documents in one case leads to a disappointing origin in RFC 2747. The other chain is shorter and more relevant, and it provides greater confidence that this document yields no new security concerns.

 

This document describes extensions to RSVP to enable creating a bidirectional LSP from two p-t-p unidirectional LSPs.

 

The security considerations section consists of just two paragraphs. The first cites the security considerations section of RFC 6780 (RSVP Association Objects) as encompassing any security issues that might arise in this context. (The assertion is that this document introduces no new signaling information, and thus no new security concerns.)

 

The Security Considerations section of 6780 is also two paragraphs in length. That text states that no new security considerations have been introduced, because no new procedures have been defined. Hence it cites the  Security Considerations sections of RFC 4872 and 4873.

 

RFC 4872 cites RFC 4426 (RFC 4873 cites RFC 4872).

 

The security considerations section of 4426 is almost a full page. It specifies security services that are required to protect the GMPLS recovery mechanisms defined in that document, but does not point to ANY security mechanisms that should be employed.

 

RFC 4872 also establishes a few security-relevant requirements for RSVP signaling, and cites RFC 2747 as specifying the required security mechanisms. (4872 also notes that IPsec could be employed for hop-by-hop integrity and authentication, and cites RFC 3473. I note that 3473 is from 2003, and thus refers to IPsec and IKE RFCs that have been obsoleted!)

 

RFC 2747 specifies crypto authentication mechanisms for RSVP, but dates from 2000. It anticipates that “ … the IETF will define a standard key management protocol†and thus omits specification of such in that document. (A fun walk down memory lane …)

 

 

The second paragraph of the Security Considerations section of this I-D notes that additional information is conveyed in the REVERSE_LSP object, but that the information is not fundamentally different from what is carried in a bidirectional LSP message. Thus, the argument is that no fundamentally different information is being transmitted. This paragraph cites RFC 5920 (Security Framework for MPLS and GMPLS Networks) as relevant. I agree that 5920 seems to be most appropriate RFC in this context.

--------------090900000005060101020601-- From nobody Fri Mar 6 13:19: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 47AB51A026C; Fri, 6 Mar 2015 10:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 5v7N6IrBlwms; Fri, 6 Mar 2015 10:04:35 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6631A037F; Fri, 6 Mar 2015 10:04:35 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0DF1FC249; Fri, 6 Mar 2015 13:04:35 -0500 (EST) Date: Fri, 6 Mar 2015 13:04:34 -0500 From: Jeffrey Haas To: Andy Bierman , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" , Melinda Shore , secdir@ietf.org Message-ID: <20150306180434.GA10092@pfrc> References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> <20150304194244.GB9142@pfrc> <20150304230940.GA68185@elstar.local> <20150305081801.GA68988@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150305081801.GA68988@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 13:19:36 -0800 Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF 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, 06 Mar 2015 18:04:36 -0000 On Thu, Mar 05, 2015 at 09:18:02AM +0100, Juergen Schoenwaelder wrote: > On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote: > > > The simple solution is to make "A B C" one atomic edit. > > > > > > > > > We use entity tags and If-Match in RESTCONF so the client can > > be sure it is editing the correct version of the resource instance. > > This works nicely for persistent configuration, especially if > > the server can reboot with the same config ETags. > > > > If-Match will cause the edit to fail if the server reboots and the > > I2RS state is gone. > > The client will get a 412 Precondition Failed response and know it might have to > > start over. > > > > RESTCONF only requires the server to maintain an ETag for the config root. > > Finer granularity (e.g., the parent resource has an ETag) is probably needed > > to support multiple concurrent edits. > > > > Thanks, this all makes sense. So there is a viable mechanism to create > a sequence of linked edits. The main trade-off, however, between a > single atomic edit and a sequence of linked edits is who is taking the > pain to cleanup the mess if things fail in the middle. If you write a > client, you love the server to do it. If you write a server, you love > the client to do it. ;-) It's all pain, but some component has to deal with it. I'm glad that restconf seems to have this situation covered, Andy. Is there a similar mechanism in netconf that I've missed? If so, this completely deals with the need for i2rs to have to ask for anything new. :-) -- Jeff From nobody Fri Mar 6 15:05: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 8D3131A6F33; Fri, 6 Mar 2015 15:05:54 -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 hXfcAHYCvyJt; Fri, 6 Mar 2015 15:05:53 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EA41A1B24; Fri, 6 Mar 2015 15:05:52 -0800 (PST) Received: by labhs14 with SMTP id hs14so60603061lab.1; Fri, 06 Mar 2015 15:05:51 -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=zRfLmAFWBsWE6nQ5ZvrPDm7lEVxZdlQ9cMWPUDvITk8=; b=u+8tVa3W2d1mFkEn2Dq96ilbigwahyjW7Vt/YFpCeuYfoMTNi80nSPGRcrFnk53fLq sv1h/+g6shErWXeTkVlvKJQDabGxkegPKxtK3t1KeL36QQpZo6mzr7B7flY0ihipx0Wr P4yTW3IiwdmE2gF8t9op3yJ50iBSx//L/WgdjxLXtSr/40Y2pHxziVTBre5pZ6WQEWgm sz+TrdpjYJFxhHYCHdvlxeGWqkOr4EIR6ImtpAfEmDIakKo5PvB0W2wIjdk/OtRFqwSW fUFmaWtcJunV0gN/0fkAPz0AFub7hkPkySsK3Yo3kYJsf4Uz1vAkWXVQM1aPk2y4KVWp c7UA== MIME-Version: 1.0 X-Received: by 10.112.51.35 with SMTP id h3mr6108862lbo.113.1425683151233; Fri, 06 Mar 2015 15:05:51 -0800 (PST) Received: by 10.112.202.65 with HTTP; Fri, 6 Mar 2015 15:05:51 -0800 (PST) Date: Fri, 6 Mar 2015 15:05:51 -0800 Message-ID: From: Radia Perlman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11336dbacaa7af0510a6b922 Archived-At: Cc: draft-ietf-lmap-framework.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: [secdir] Secdir review of draft-ietf-lmap-framework-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 23:05:54 -0000 --001a11336dbacaa7af0510a6b922 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 17, 2015 at 10:24 AM, Benoit Claise wrote: > Thanks Radia for your review. > The authors have posted the v10. I believe it addresses your feedback. > > https://www.ietf.org/rfcdiff?url1=draft-ietf-lmap-framework-08&difftype=--html&submit=Go!&url2=draft-ietf-lmap-framework-10 > I would appreciate if you could double-check. > > Regards, Benoit > Yes, indeed the new version addresses my feedback. It is fine. Thank you, Radia --001a11336dbacaa7af0510a6b922 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 17, 2015 at 10:24 AM, Benoit Claise <<= a href=3D"mailto:bclaise@cisco.com" target=3D"_blank">bclaise@cisco.com= > wrote:
=20 =20 =20
Thanks Radia for your review.
The authors have posted the v10. I believe it addresses your feedback.
https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-lmap= -framework-08&difftype=3D--html&submit=3DGo!&url2=3Ddraft-ietf-= lmap-framework-10
I would appreciate if you could double-check.

Regards, Benoit

Yes, = indeed the new version addresses my feedback.=C2=A0 It is fine.=C2=A0 Thank= you,

Radia=C2=A0

--001a11336dbacaa7af0510a6b922-- From nobody Fri Mar 6 19:36:55 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 2F66F1A1BDC; Fri, 6 Mar 2015 19:36:53 -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 ezCVf1jUVrCB; Fri, 6 Mar 2015 19:36:51 -0800 (PST) Received: from COL004-OMC4S6.hotmail.com (col004-omc4s6.hotmail.com [65.55.34.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604C31A00EC; Fri, 6 Mar 2015 19:36:51 -0800 (PST) Received: from COL401-EAS166 ([65.55.34.201]) by COL004-OMC4S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 6 Mar 2015 19:36:51 -0800 X-TMN: [9SAeI4aVyd9GcVz5axexMrRtnZaVaTG2] X-Originating-Email: [charliekaufman@outlook.com] Message-ID: From: Charlie Kaufman To: Date: Fri, 6 Mar 2015 19:36:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBYghT9Omda/yxXSmeeerKGSxaeiA== Content-Language: en-us X-OriginalArrivalTime: 07 Mar 2015 03:36:51.0210 (UTC) FILETIME=[F2DC56A0:01D05887] Archived-At: Cc: draft-ietf-oauth-dyn-reg.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Secdir review of draft-ietf-oauth-dyn-reg-24 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, 07 Mar 2015 03:36:53 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies a protocol whereby an instance of installed software on a node can register itself with an OAuth 2.0 authorization server and in doing so (normally) acquire a secret to be used in subsequent authentications. According to the introduction: "This specification generalizes the registration mechanisms defined by the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification and used by the User Managed Access (UMA) Profile of OAuth 2.0 [I-D.hardjono-oauth-umacore] specification in a way that is compatible with both, while being applicable to a wider set of OAuth 2.0 use cases." I am not an expert on the evolution of OAuth, and I would expect others on Secdir are, so they be more able to evaluate the goodness of the particular design decisions, but this appears to me to be consistent with the way OAuth does related things and the particular attributes that this document specifies as being relevant to the process seem right. The security considerations section of the document is somewhat unorthodox in that it specifies security aspects of the protocol (e.g., that it MUST run over TLS 1.2 and MAY run over other transport-layer mechanisms. In most recent RFCs, the security considerations section is not normative but rather reviews the security aspects of the protocol. I'm not objecting though... this organization seems entirely reasonable. I will throw in one vague concern and one specific issue: 1) This document is all about infrastructure to allow software (as opposed to the end user or service using the software) to authenticate itself. This has been the holy grail of many authorization architectures for a long time, but the technology to accomplish it securely is by and large still not in place. I worry that specifying protocols for doing it might fool people into thinking they are getting more security than they really are. There may be some other document containing the rationale and scenarios for attempting this, but it was not obvious (at least to me) from reading the document. 2) The software_version values are specified as opaque where the only operation to be done on them is comparisons for equality. It's not clear (at least to me) the intended usage of this field, but generally version numbers work best when they have multiple parts (at least major version and minor version and sometimes lower level indicators) and where the different parts can be compared for "greater than" and "less than" in addition to tests for equality. That allows forward compatibility when a new version is released that is intended to be compatible with an existing version while detecting incompatibility in the case where a major version number changes. --Charlie From nobody Sat Mar 7 07:33:54 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 B95AB1A90F9; Sat, 7 Mar 2015 07:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=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 ZOyNX55R66JZ; Sat, 7 Mar 2015 07:33:46 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E321A90F4; Sat, 7 Mar 2015 07:33:46 -0800 (PST) Received: by igbhl2 with SMTP id hl2so10246292igb.0; Sat, 07 Mar 2015 07:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:references:mime-version:message-id :content-type; bh=NBLG47+OUYH0oT9U+sUaEvGMf7kAJvpotD6aEqi+lfc=; b=wREcfhdePKMKTGu3Ut1WYjNDls7iEVOVNv7+V0SZaXloz1nlxEzkRr+dEAhm5f4WW7 kDNIXwIs2IEaK7cmIoqkmMKK9bjRo0lQTMZvnjst7WOckY0763ud/H4PYoHtIQcSGajF b7fztzDo9QCG/VF6pmRNYz0NNIxje/e65JsWT0HBDZL5Rd4ngZyMztf9mRm94caDw9kU GOvI7sS0z0bA/aYbVFMU/IOO5w2Pq79TdvzOYxKsh+jJ7SlcxtIePKqbTGnZmAjc/06W lMj06cQ7Msmo7wSO+Jndukdb9WOeFifT/cM1NOGZAka0JO3RYyxw7tryELeYfjsdW+8C vhFQ== X-Received: by 10.50.222.70 with SMTP id qk6mr61292992igc.47.1425742425684; Sat, 07 Mar 2015 07:33:45 -0800 (PST) Received: from Lizhong ([118.132.61.135]) by mx.google.com with ESMTPSA id x10sm2834252igl.13.2015.03.07.07.33.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Mar 2015 07:33:44 -0800 (PST) Date: Sat, 7 Mar 2015 23:34:00 +0800 From: "lizho.jin@gmail.com" To: turners , draft-ietf-mpls-lsp-ping-relay-reply , secdir , iesg , ietf References: X-Priority: 3 X-GUID: 8436043E-B8A4-4F6A-AFAE-32CF90514F8F X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 140[en] Mime-Version: 1.0 Message-ID: <2015030723335400131415@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart033887510674_=----" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply 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, 07 Mar 2015 15:33:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart033887510674_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2VhbiBUdXJuZXINClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gSSBhbSBzbyBzb3JyeSB0 byByZXBseSBhZnRlciBhIGxvbmcgdGltZS4gV2UgbmVlZCB0byB1cGRhdGUgdGhlIGRvY3VtZW50 IGFjY29yZGluZyB0byBHZW9yZ2UncyBjb21tZW50cy4NCk5vdyB3ZSBoYXZlIHBvc3QgdjcsIFVS TDogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tcGxzLWxz cC1waW5nLXJlbGF5LXJlcGx5LTA3LnR4dA0KVGhlIGNoYW5nZSBsaXN0cyBhcmUgYXMgYmVsb3c6 DQoxLiBhZGQgYSBkZXN0aW5hdGlvbiBwb2ludCBpbiBzdGFjayBUTFYgdG8gYXZvaWQgcG90ZW50 aWFsIGxvb3AuDQoyLiBhZGQgYSBzb3VyY2UgYWRkcmVzcyBpbiBzdGFjayBUTFYsIHRoZW4gdGhl IGluaXRpYXRvciBjb3VsZCBnZXQgdGhlIHJlcGx5aW5nIG5vZGUgYWRkcmVzcy4NCkkgYWxzbyBy ZXBseSBpbmxpbmUgdG8geW91ciBxdWVzdGlvbnMgYXMgYmVsb3cuIFRoYW5rIHlvdS4NCg0KDQoN ClJlZ2FyZHMNCkxpemhvbmcNCiANCkZyb206IFNlYW4gVHVybmVyDQpEYXRlOiAyMDE0LTEyLTE0 IDAzOjI5DQpUbzogZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLXJlbGF5LXJlcGx5OyBzZWNkaXI7 IFRoZSBJRVNHOyBpZXRmDQpTdWJqZWN0OiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbXBs cy1sc3AtcGluZy1yZWxheS1yZXBseQ0KRG8gbm90IGJlIGFsYXJtZWQuICBJIGhhdmUgcmV2aWV3 ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZQ0Kc2VjdXJpdHkgZGlyZWN0b3JhdGXigJlz IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcNCnByb2Nl c3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBp bnRlbnQNCm9mIGltcHJvdmluZyBzZWN1cml0eSByZXF1aXJlbWVudHMgYW5kIGNvbnNpZGVyYXRp b25zIGluIElFVEYgZHJhZnRzLg0KQ29tbWVudHMgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwg bWF5IGJlIGluY2x1ZGVkIGluIEFEIHJldmlld3MNCmR1cmluZyB0aGUgSUVTRyByZXZpZXcuICBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0DQp0aGVzZSBjb21tZW50 cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCiANClZlcnNpb246IDA2 DQpTdW1tYXJ5OiBSZWFkeSB3aXRoIHNvbWUgbm9uLXNlY3VyaXR5L25vbi1wcml2YWN5IG5pdHMu DQogDQpQaW5nIG1lY2hhbmlzbXMgYWx3YXlzIGdpdmUgbWUgdGhlIGhlZWJpZS1qZWViaWVzIFsx XQ0KYmVjYXVzZSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYXNzb2NpYXRlZCB3aXRoIHRoZW0g KGkuZS4sIERvUywgDQpzcG9vZmluZy9oaWphY2tpbmcvZXRjLiwgYW5kIHVuYXV0aG9yaXplZCBk aXNjbG9zdXJlKS4gIFRoaXMgZG9jdW1lbnQNCnNwZWNpZmllcyBhbiBleHRlbnNpb24gdG8gdGhl IGV4aXN0aW5nIEVDSE8gbWVjaGFuaXNtIGluIFJGQyA0Mzc5DQphbmQgaXQgZG9lcyBub3RoaW5n IHRvIGFkZHJlc3MgdGhlc2UgY29uY2VybnMgaW4gZmFjdCBpdCBpbmNyZWFzZXMgdGhlDQpjb25j ZXJucyB3cnQgRG9TLiAqQlVUKiBpdCByaWdodGx5IHBvaW50cyB0aGlzIGluY3JlYXNlIGV4cG9z dXJlIG91dCBpbg0KdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uICBJdCBwcm92 aWRlcyByZW1lZGlhdGlvbiB0ZWNobmlxdWVzDQpzaW1pbGFyIHRvIHRob3NlIHNwZWNpZmllZCBp biBSRkMgNDM3OTogcmF0ZSBsaW1pdCBhbmQgdmFsaWRhdGUgc291cmNlDQphZ2FpbnN0IGFjY2Vz cyBsaXN0LiAgVGhpcyBkcmFmdCwgdW5saWtlIFJGQyA0Mzc5LCBkb2VzIHJlY29tbWVuZCB0aGF0 DQpvcGVyYXRvcnMgd2lzaGluZyB0byBub3QgZGlzY2xvc2UgdGhlaXIgbm9kZXMgYmxhbmsgdGhl IGFkZHJlc3Mgb3V0IGluDQp0aGUgVExWLiAgVGhpcyBkcmFmdCBhbHNvIHJlZmVycyB0byBSRkMg NDM3OSBmb3IgYWRkaXRpb25hbCBzZWN1cml0eQ0KY29uc2lkZXJhdGlvbnMuDQogDQpXQVJOSU5H IC0gcXVlc3Rpb25zIGFuZCBuaXRzIGZvbGxvdzoNCiANCnMzIC0gMXN0IHBhcmFncmFwaDogUmVs YXllZCBFY2hvIFJlcGx5IOKAnHJlcGxhY2Vz4oCdIEVjaG8gUmVwbHkgLSBkb2VzIHRoaXMNCm1l YW4geW914oCZcmUgZGVwcmVjYXRpbmcgdGhlIHVzZSBvZiDigJxFY2hvIFJlcGx54oCdPw0KW0xp emhvbmddIG5vLiBUaGUgcmVwbHkgbWVzc2FnZSBmcm9tIGFueSBub2RlIHRvIGluaXRpYXRvciB3 aWxsIHN0aWxsIGJlIEVjaG8gUmVwbHkuDQpCdXQgdGhlIHJlcGx5IG1lc3NhZ2UgZnJvbSByZXBs eWluZyBMU1IgdG8gYSByZWxheSBub2RlIG9yIGZyb20gYSByZWxheSBub2RlIHRvIA0KYW5vdGhl ciByZWxheSBub2RlIHdpbGwgYmUgUmVsYXllZCBFY2hvIFJlcGx5Lg0KIA0KczQuMTogSXMgdGhl IG91dGVybW9zdCBsYWJlbCBhbGxvd2VkIHRvIGJlIHNldCB0byAyNTUgdG8gc3VwcG9ydCB0aGUN CuKAnHBpbmfigJ0gbW9kZSBvciBtdXN0IGl0IGFsd2F5cyBiZSBzZXQgdG8gMSwgMiwgZXRjLiB0 byBzdXBwb3J0IOKAnHRyYWNlcm91dGUiDQptb2RlIC0gYXMgZGVzY3JpYmVkIGluIFJGQyA0Mzc5 IHM0LjM/ICAgSSBrbm93IHM1IGlzIGp1c3QgYW4gZXhhbXBsZQ0KYnV0IGl0IHJlYWxseSBsb29r cyBsaWtlIHRoaXMgZXh0ZW5zaW9uIGlzIGp1c3Qgc3VwcG9zZWQgdG8gYmUgZm9yIGZhdWx0DQpp c29sYXRpb24uDQpbTGl6aG9uZ10gSXQgaXMgcG9zc2libGUgdG8gc2V0IDI1NS4gT25lIGltcGxl bWVudGF0aW9uIGluIG15IG1pbmQgaXMgdG8gbWFudWFsbHkNCmdlbmVyYXRlIHRoZSBzdGFjayBU TFYgbGlzdCwgYW5kIHRoZSByZXBseWluZyBMU1IgY291bGQgc3RpbGwgcmVsYXkgdGhlIG1lc3Nh Z2UgYmFjaw0KdG8gdGhlIGluaXRpYXRvciBhY2NvcmRpbmcgdG8gdGhlIHJlY2VpdmVkIHN0YWNr IFRMViBsaXN0LiBUaGUgY2FzZSBpbiB0aGUgZG9jdW1lbnQgaXMNCmZvciBzdGFjayBUTFYgbGlz dCBhdXRvIGxlYXJuaW5nLg0KIA0KczQuMSAtIGxhc3QgcGFyYWdyYXBoOiBEb2VzIHRoZSBuZXh0 IGluaXRpYXRvciBwdXQgaXTigJlzIGFkZHJlc3MgaW4gdGhlIHN0YWNrDQpiZWZvcmUgb3IgYWZ0 ZXIgdGhlIHByZXZpb3VzIGluaXRpYXRvcj8gIEkgYXNzdW1lIGl04oCZcyBhZnRlciwgYnV0IEkg bWF5YmUNCm1pc3NlZCB0aGF0IHBhcnQ/ICBXb3VsZCBiZSBnb29kIHRvIHN0YXRlIHRoYXQgZXhw bGljaXRseS4NCltMaXpob25nXSBhcmUgeW91IHJlZmVycmluZyB0byBzZWN0aW9uIDQuMi4gVGhl cmUgaXMgc29tZSBjaGFuZ2UgaW4gdjcuIFBsZWFzZSBoZWxwDQp0byBjaGVjayBhZ2FpbiwgdG8g c2VlIGlmIHRoYXQgaXMgT0sgZm9yIHlvdSBub3cuDQogDQpDaGVlcnMsDQpzcHQNCiANClsxXSBo dHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0hlZWJpZS1qZWViaWVzXyhpZGlvbSkNCg== ------=_001_NextPart033887510674_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <= /head>=0A
Hi Sean Turner
Thank you for th= e review. I am so sorry to reply after a long time. We need to update the = document according to George's comments.
The change lists are as below:
1. add a destination po= int in stack TLV to avoid potential loop.
2. add a source addres= s in stack TLV, then the initiator could get the replying node a= ddress.
I also reply inline to your questions as bel= ow. Thank you.
=0A

=0A
Regard= s
Lizhong
=0A
 
Date: 2014-12-14 03:29
Subject: secdir review of draft-ietf-mpls-lsp-ping-relay-reply
Do not be alarmed.  I have reviewed this document as pa= rt of the
=0A
security directorate=E2=80=99s ongoing effort to re= view all IETF documents being
=0A
processed by the IESG.  Th= ese comments were written with the intent
=0A
of improving securi= ty requirements and considerations in IETF drafts.
=0A
Comments n= ot addressed in last call may be included in AD reviews
=0A
durin= g the IESG review.  Document editors and WG chairs should treat
= =0A
these comments just like any other last call comments.
=0A 
=0A
Version: 06
=0A
Summary: Ready with some no= n-security/non-privacy nits.
=0A
 
=0A
Ping mechani= sms always give me the heebie-jeebies [1]
=0A
because of the secu= rity concerns associated with them (i.e., DoS,
=0A
spoofing/hija= cking/etc., and unauthorized disclosure).  This document
=0Aspecifies an extension to the existing ECHO mechanism in RFC 4379
= =0A
and it does nothing to address these concerns in fact it increases= the
=0A
concerns wrt DoS. *BUT* it rightly points this increase = exposure out in
=0A
the security considerations section.  It= provides remediation techniques
=0A
similar to those specified i= n RFC 4379: rate limit and validate source
=0A
against access lis= t.  This draft, unlike RFC 4379, does recommend that
=0A
ope= rators wishing to not disclose their nodes blank the address out in
= =0A
the TLV.  This draft also refers to RFC 4379 for additional s= ecurity
=0A
considerations.
=0A
 
=0A
WARN= ING - questions and nits follow:
=0A
 
=0A
s3 - 1st= paragraph: Relayed Echo Reply =E2=80=9Creplaces=E2=80=9D Echo Reply - doe= s this
=0A
mean you=E2=80=99re deprecating the use of =E2=80=9CEc= ho Reply=E2=80=9D?
[Lizhong] no. The reply message from any node= to initiator will still be Echo Reply.
=
But the reply message from rep= lying LSR to a relay node or from a relay node to 
<= span style=3D"font-family: ''; font-size: 10.5pt; line-height: 1.5; backgr= ound-color: window;">another relay node = will be Relayed Echo Reply.
 
= =0A
s4.1: Is the outermost label allowed to be set to 255 to support t= he
=0A
=E2=80=9Cping=E2=80=9D mode or must it always be set to 1,= 2, etc. to support =E2=80=9Ctraceroute"
=0A
mode - as described = in RFC 4379 s4.3?   I know s5 is just an example
=0A
bu= t it really looks like this extension is just supposed to be for fault=0A
isolation.
[Lizhong] It is possible to set 255. One im= plementation in my mind is to manually
generate the stack TLV li= st, and the replying LSR could still relay the message back
to the initiator according to the received <= span style=3D"font-size: 10.5pt; line-height: 1.5; background-color: windo= w;">stack TLV list. The case in the document is
for = stack TLV list auto learning.
=0A
 
=0As4.1 - last paragraph: Does the next initiator put it=E2=80=99s address i= n the stack
=0A
before or after the previous initiator?  I a= ssume it=E2=80=99s after, but I maybe
=0A
missed that part? = Would be good to state that explicitly.
[Lizhong] are you refer= ring to section 4.2. There is some change in v7. Please help
to = check again, to see if that is OK for you now.
=0A
 
= =0A
Cheers,
=0A
spt
=0A
 
=0A
[1] http= ://en.wikipedia.org/wiki/Heebie-jeebies_(idiom)
=0A
=0A ------=_001_NextPart033887510674_=------ From nobody Sat Mar 7 12:16:53 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 2FBEA1A8782; Fri, 6 Mar 2015 16:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1425688887; bh=tINjCwVV0SpnKCqcyv0NwLH36Ww49Qn2XoHaPySqJZE=; 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=kCKCPRk8YMU4ViKyiLpIpvKlUKh9V9IUesh3wsvLDq5ITzjHDx1a8mGupty+WUbpz dMK17CZRCWqPXY7zGGHOBGqOh7PrcZ8A+GVZraj3frpZ16O1TbZOzjuDFCGRwtUOIM l9tmqq1PNMhhNz7c1RMM4Re8Z+WyWAvyyIblO8go= 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 C171E1A8787; Fri, 6 Mar 2015 16:41:24 -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 dE60q41XnEAA; Fri, 6 Mar 2015 16:41:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F397E1A8782; Fri, 6 Mar 2015 16:41:20 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307004120.29910.50845.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:41:20 -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: Sat, 07 Mar 2015 12:16:52 -0800 Subject: [secdir] [new-work] WG Review: Domain Boundaries (dbound) 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: Sat, 07 Mar 2015 00:41:27 -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-03-16. Domain Boundaries (dbound) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: dbound@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dbound Archive: http://www.ietf.org/mail-archive/web/dbound Charter: Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of "related" in this context is not a unitart concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant. For example, it is often necessary or useful to determine whether example.com and foo.example.com, or even example.net, are subject to the same administrative control. To humans, the answer to this may be obvious. However, the Domain Name System (DNS), which is the service that handles domain name queries, does not provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. The right answer is not always "compare the rightmost two labels". Applications and organizations impose policies and procedures that create additional structure in their use of domain names. This creates many possible relationships that are not evident in the names themselves or in the operational, public representation of the names. Prior solutions for identifying relationships between domain names have sought to use the DNS namespace and protocol to extract that information when it isn't actually there. See the "Additional Background Information" section, below, for more details. For the purpose of this work, domain names are identifiers used by organizations and services, independent of underlying protocols or mechanisms. We define an "organizational domain" to be a name that is at the top of an administrative hierarchy, defining transition from one "outside" administrative authority to another that is "inside" the organization. The current way most of this is handled is via a list published at publicsuffix.org, and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. Solutions will not involve the proposal of any changes to the DNS protocol. They might involve the creation of new resource record types. This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) without rechartering, and such rechartering will only be considered after completion of the base work. The working group has a pre-IETF draft to consider as a possible starting point: draft-sullivan-dbound-problem-statement Milestones: - TBD Additional Background Information --------------------------------- [to be moved to a Wiki on chartering] The concept of an administrative boundary is by definition not present in the DNS. Relying on the DNS to divine administrative structure thus renders such solutions unreliable and unnecessarily constrained. For example, confirming or dismissing a relationship between two domain names based on the existence of a zone cut or common ancestry is often unfounded, and the notion of an upward "tree walk" as a search mechanism is, therefore, unacceptable. Currently, the most well known solution in existence is the Public Suffix List (PSL). The PSL is maintained by a web browser producer and is kept current by volunteers on a best-effort basis. It contains a list of points in the hierarchical namespace at which registrations take place, and is used to identify the boundary between so-called "public" names (below which registrations can occur, such as ".com" or ".org.uk") and the private names (organizational names) that domain registrars create within them. When this list is inaccurate, it exposes a deviation from reality that degrades service to some and can be exploited by others. As the PSL is the de-facto resource, and as there is not a more comprehensive, alternative solution for relationship identification, the PSL has often been misused to accomplish things beyond its capabilities. For example, there is no way to confirm the relationship between two domain names -- the PSL may only signal that there is or is not a public boundary between the two. Additionally, there are questions about the scalability, central management, and third-party management of the PSL as it currently exists. In terms of specific use cases, within the realm of email there is a desire to link an arbitrary fully-qualified domain name (FQDN) to the organizational domain name (at some point in the namespace above it), in order to identify a deterministic location where some sort of statement of policy regarding that FQDN can be found. With respect to the web, there is a similar need to identify relationships between different FQDNs, currently accomplished by comparing ancestries. However, there is also desire to reliably identify relationships outside of the realm and constraints of the namespace tree. Work such as DMARC (draft-kucherawy-dmarc-base), will certainly benefit from having this capability. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Mar 9 05:10:45 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 190541A8833; Mon, 9 Mar 2015 05:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_SOFTFAIL=0.665] 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 3YD37JgE2T6r; Mon, 9 Mar 2015 05:10:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A151A878A; Mon, 9 Mar 2015 05:10:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 36CB120655; Mon, 9 Mar 2015 08:09:24 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5YmM7uykHrU; Mon, 9 Mar 2015 08:09:23 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 9 Mar 2015 08:09:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A3BD80430; Mon, 9 Mar 2015 08:10:24 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org,secdir@ietf.org,iesg@ietf.org Date: Mon, 09 Mar 2015 08:10:24 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-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, 09 Mar 2015 12:10:42 -0000 This is an update to netconf over TLS with mutual X.509 authentication. In general, this looks fairly good. I'd ask the security ADs to take a look at two things: * The text on certificate validation in section 5. Certificate validation has a number of options, none of which are described or specified in this text. Is that good enough for this application? (Probably) In section 7, there is a description of how the netconf server finds the username of the client. It talks about a certificate fingerprint without a reference to a specific algorithm. I'm aware of multiple algorithms for fingerprints. This text is probably too vague for interoperability. From nobody Mon Mar 9 15:35: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 5F6021ACDE9; Mon, 9 Mar 2015 15:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 J5gozVU1ncrQ; Mon, 9 Mar 2015 15:35:44 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 1E3501ACDF6; Mon, 9 Mar 2015 15:35:29 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t29MZNB9023499 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Mar 2015 18:35:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t29MZNB9023499 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1425940524; bh=9y9uPrIw7gaa9CQh/cAx6bAGhFY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KCFYQ0N8atDQCbLvsHV8S7z8b5yCDoCT+azhfqf12tGmoKRsdez479JFRuE2ekKGQ AhkS/cOJ8krMFHKmWA/9QTQ68XJKR4HjuzDBRpCUx3Y9IjQnofgTxCjM5/IS60xuHT DZmgSrNnf+w+XsYl1SgrW0J3j2JThjhjY+f0pQ9E= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t29MZNB9023499 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Mon, 9 Mar 2015 18:34:07 -0400 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t29MZAWR026746 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 18:35:10 -0400 Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 9 Mar 2015 18:35:09 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.227]) by MXHUB207.corp.emc.com ([10.253.68.33]) with mapi id 14.03.0224.002; Mon, 9 Mar 2015 18:35:09 -0400 From: "Moriarty, Kathleen" To: "Klaas Wierenga (kwiereng)" Thread-Topic: [secdir] review of draft-iab-2870bis-01 Thread-Index: AQHPe+CHOiNbHuQdUUWnnFqhc5tLF50WetYs Date: Mon, 9 Mar 2015 22:35:07 +0000 Message-ID: <15A1776F-0C24-42EE-8EFF-578DA2A0D140@emc.com> References: <0B5213DB-58F9-4947-BB2E-D5EACC0C42FB@cisco.com> In-Reply-To: <0B5213DB-58F9-4947-BB2E-D5EACC0C42FB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "draft-iab-2870bis.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] review of draft-iab-2870bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:35:46 -0000 Hi Klaas, Thanks for your review of this draft. Sent from my iPhone > On May 30, 2014, at 4:24 AM, "Klaas Wierenga (kwiereng)" wrote: >=20 > Hi, >=20 > 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 specifies he protocol and deployment requirements expected = to be implemented for the DNS root name service, operational requirements a= re taken out of 2870, those are published separately (one hopes, see below)= . > The document is short (thank you! ;-) and clear. I consider it ready with= a few issues: >=20 > =3D=3D=3D >=20 > - paragraph 3 (deployment requirements): >=20 > "The root name service: >=20 > MUST answer queries from any entity conforming to [RFC1122] with a > valid IP address.=94 >=20 > I find this a bit confusing. Perhaps showing my ignorance, but should it = not be be =93=85 with a valid IP-address or a referral to an authoritative = name server=94? This text is getting updated as others found it confusing as well, good cat= ch. >=20 > - paragraph 4 (security considerations): >=20 > This is a bit weak imo.=20 Yes, but I'll let it slide (Stephen may have a different opinion) as I thin= k it would be better to deal with the specific security and privacy conside= rations in each of the referenced RFCs if they get updated. Thanks again! Kathleen >=20 > At the very least I would expect some discussion about privacy here or in= a separate section =93privacy considerations=94, queries to the root give = good insight into what sites the requester is visiting, mitigated by the fa= ct that most queries will not reach the root due to caching of responses. I= n any case worth some discussion in the era of pervasive surveillance=85. >=20 > Furthermore, the reference to [RSSAC-001] leads to a list of members of R= SSAC, not to a document. A quick search at the RSSAC site also didn=92t get= me to any document called "Service Expectations of Root Servers=94, only t= o the project that was supposed to deliver it. I think you need to fix that= reference. >=20 > =3D=3D=3D >=20 > Hope this helps, >=20 > Klaas >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 From nobody Tue Mar 10 05:34:31 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 325DE1ACD54; Tue, 10 Mar 2015 05:32:56 -0700 (PDT) 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, 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 yPQQojV_aimY; Tue, 10 Mar 2015 05:32:53 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021BA1ACDB2; Tue, 10 Mar 2015 05:32:52 -0700 (PDT) Received: from AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) by AM3PR07MB0711.eurprd07.prod.outlook.com (25.160.6.15) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 12:15:17 +0000 Received: from pc6 (86.185.85.149) by AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 12:15:16 +0000 Message-ID: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> From: t.p. To: Sam Hartman , , , References: Date: Tue, 10 Mar 2015 12:12:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB4PR02CA0028.eurprd02.prod.outlook.com (10.242.174.156) To AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB242; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0711; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51704005)(129404003)(33646002)(50226001)(61296003)(116806002)(1556002)(86362001)(50466002)(230783001)(19580405001)(23756003)(19580395003)(44716002)(87976001)(2201001)(77096005)(77156002)(62966003)(47776003)(42186005)(40100003)(46102003)(76176999)(92566002)(62236002)(122386002)(81686999)(81816999)(66066001)(44736004)(50986999)(1456003)(2171001)(84392001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB242; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:AM3PR07MB242; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB242; X-Forefront-PRVS: 051158ECBB X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2015 12:15:16.6850 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB242 X-OriginatorOrg: btconnect.com Archived-At: X-Mailman-Approved-At: Tue, 10 Mar 2015 05:34:29 -0700 Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-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: Tue, 10 Mar 2015 12:32:56 -0000 ----- Original Message ----- From: "Sam Hartman" To: ; ; Cc: Sent: Monday, March 09, 2015 12:10 PM Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09 > > This is an update to netconf over TLS with mutual X.509 authentication. > > In general, this looks fairly good. > > I'd ask the security ADs to take a look at two things: > > * The text on certificate validation in section 5. > Certificate validation has a number of options, none of which are > described or specified in this text. > Is that good enough for this application? (Probably) > > In section 7, there is a description of how the netconf server finds the > username of the client. > It talks about a certificate fingerprint without a reference to a > specific algorithm. > I'm aware of multiple algorithms for fingerprints. > This text is probably too vague for interoperability. Sam I see what you mean but had a different model in mind. The fingerprint is not transmitted as part of the tls/netconf protocol, I assume that it is only generated within a server when a certificate arrives over the tls/netconf protocol and is then compared with a prestored list of fingerprints within the server. So as long as the same algorithm is used within the server, then it does not matter what is used. If, instead, the prestored list of fingerprints is generated outside the server and installed as a file, then yes, the algorithm used to create the prestored list must be the same as that used within the server when a certificate arrives over the tls/netconf protocol. That is the only issue I can see. However, this I-D used to contain a data model to go with it but that has been put into a different I-D namely netconf-server. That data model imports a YANG data type tls-fingerprint which is defined as a one octet hashing algorithm identifier followed by the fingerprint value. The octet value is taken from the IANA TLS Hash Algorithm Registry (RFC 5246). So if the YANG data model is used, then the algorithm is part of the model and the server can look up what has been used in its prestored list of fingerprints. If users do not use the YANG data model, well that is up to them Hope this helps Tom Petch > From nobody Tue Mar 10 05:48: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 CA13F1ACDE8; Tue, 10 Mar 2015 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_SOFTFAIL=0.665] 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 irjRIYSesrrG; Tue, 10 Mar 2015 05:48:07 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA75E1A882E; Tue, 10 Mar 2015 05:48:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9E3A820659; Tue, 10 Mar 2015 08:47:01 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWt2aeH96Q4Y; Tue, 10 Mar 2015 08:47:00 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 10 Mar 2015 08:47:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ED7C382837; Tue, 10 Mar 2015 08:48:04 -0400 (EDT) From: Sam Hartman To: "t.p." References: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> Date: Tue, 10 Mar 2015 08:48:04 -0400 In-Reply-To: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> (t. p.'s message of "Tue, 10 Mar 2015 12:12:14 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-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: Tue, 10 Mar 2015 12:48:09 -0000 >>>>> "t" == t p writes: Well, I think you still need to answer questions like * Is it a fingerprint of the cert or the key? * Is the server expected to re-normalize the DER? Allowed to re-normalize the DER? So that the input to the hash is well specified. Several protocols within the IETF have taken on the challenge of describing how to fingerprint certificates. I think the document would be improved by picking one of these strategies. From nobody Tue Mar 10 05:59: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 8C1BB1A87A8; Tue, 10 Mar 2015 05:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 YwZ_DIwycpj2; Tue, 10 Mar 2015 05:59:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE3D1A886E; Tue, 10 Mar 2015 05:59:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE810A31; Tue, 10 Mar 2015 13:59:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id m86mO68B2l0E; Tue, 10 Mar 2015 13:59:11 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Mar 2015 13:59:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 486DC2003D; Tue, 10 Mar 2015 13:59:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8n1j5og9Piuc; Tue, 10 Mar 2015 13:59:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7607D2003C; Tue, 10 Mar 2015 13:59:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6953B3275FAB; Tue, 10 Mar 2015 13:59:18 +0100 (CET) Date: Tue, 10 Mar 2015 13:59:18 +0100 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20150310125918.GD6978@elstar.local> Mail-Followup-To: Sam Hartman , ietf@ietf.org, secdir@ietf.org, iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 12:59:24 -0000 On Mon, Mar 09, 2015 at 08:10:24AM -0400, Sam Hartman wrote: > > In section 7, there is a description of how the netconf server finds the > username of the client. > It talks about a certificate fingerprint without a reference to a > specific algorithm. > I'm aware of multiple algorithms for fingerprints. > This text is probably too vague for interoperability. Since the fingerprints are not exchanged over the wire, this is a local problem. That said, there is a YANG configuration data model in draft-ietf-netconf-server-model-06 that clarifies details for those implementations that want interoperable configuration and this data model uses tls-fingerprint defined in RFC 7407. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 10 06:37: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 9BF1F1A88A4 for ; Tue, 10 Mar 2015 06:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 vuJ2zL41Kmcu for ; Tue, 10 Mar 2015 06:37:18 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB6E1A8901 for ; Tue, 10 Mar 2015 06:36:56 -0700 (PDT) Received: from smtp1.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 969A8180550; Tue, 10 Mar 2015 09:36:55 -0400 (EDT) Received: from app47.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6C6F9180542; Tue, 10 Mar 2015 09:36:55 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from app47.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Tue, 10 Mar 2015 13:36:55 GMT Received: from ogud.com (localhost.localdomain [127.0.0.1]) by app47.wa-webapps.iad3a (Postfix) with ESMTP id 42DD438004E; Tue, 10 Mar 2015 09:36:55 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Tue, 10 Mar 2015 09:36:55 -0400 (EDT) Date: Tue, 10 Mar 2015 09:36:55 -0400 (EDT) From: "Olafur Gudmundsson" To: secdir@ietf.org, iesg@ietf.org, draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20150310093655000000_34834" Importance: Normal X-Priority: 3 (Normal) X-Type: html X-Auth-ID: ogud@ogud.com Message-ID: <1425994615.27221597@apps.rackspace.com> X-Mailer: webmail/11.3.13-RC Archived-At: Subject: [secdir] sec-dir review of draft-ietf-bfcpbis-rfc4582bis-13 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, 10 Mar 2015 13:37:19 -0000 ------=_20150310093655000000_34834 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These= comments were written with the intent of improving security requirements a= nd 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.= =0A =0A =0AThis document is a replacement document for RFC4582 =0A =0A =0A = =0AThe document is well written and is ready to be published with a Nit.=0A= I did not look for textual nits only evaluated=0A =0Athe document from secu= rity perspective.=0A =0A =0A =0AAuthenticaion and message integrity are rec= ommended but outsourced to =0A =0ATLS, and DTLS. =0A =0A =0ANit: The securi= ty section does address the issues of pervasive monitoring. =0A =0AIt does = not provide any information what an obsever=0A =0Amay learn by sniffing tra= ffic at the BFCP server, i.e. other than=0A =0Adiscover participants IP add= resses, possibly their identies depending=0A =0Aon how authentication is do= ne, as well as their roles and actions? =0A =0AOlafur=0A =0A ------=_20150310093655000000_34834 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG.&nb= sp; These comments were written with= the intent of improving security requirements and considerations in IETF d= rafts.  Comments not addr= essed in last call may be included in AD reviews during the IESG review.  Document editors and WG ch= airs should treat these comments just like any other last call comments.

=0A

 

=0A

 

=0A

This docum= ent is a replacement document for RFC4582 

=0A

&nbs= p;

=0A

 

=0A

 

=0A

The document is w= ell written and is ready to be published with a Nit.

=0A

I did not look for tex= tual nits only evaluated

=0A

 

=0A

the document from se= curity perspective.

=0A

 

=0A

 <= /p>=0A

 

=0A

Authenticaion and message integrity are recom= mended but outsourced to 

=0A

 

=0A

TLS, and = DTLS. 

=0A

 

=0A

 

=0ANit: The= security section does address the issues of pervasive monitoring. =0A

 

=0A

It does not provide any information what an obs= ever

=0A

 

=0A

may learn by sniffing traffic at the BFC= P server, i.e. other than

=0A

 

=0A

discover participan= ts IP addresses, possibly their identies depending

=0A

&= nbsp;

=0A

on how authentication is done, as well as their roles and actions?&nb= sp;

=0A

 

=0A

Olafur

=0A

 

=0A

 

 ------=_20150310093655000000_34834-- From nobody Tue Mar 10 07:18:58 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 3EB021A00F6; Tue, 10 Mar 2015 07:18:51 -0700 (PDT) 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, 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 w-TUujyrm9Ct; Tue, 10 Mar 2015 07:18:49 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678481A6FF5; Tue, 10 Mar 2015 07:18:49 -0700 (PDT) Received: from pc6 (86.185.85.149) by AMSPR07MB248.eurprd07.prod.outlook.com (10.242.19.27) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 14:18:25 +0000 Message-ID: <006c01d05b3c$c44eac40$4001a8c0@gateway.2wire.net> From: t.p. To: Sam Hartman References: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> Date: Tue, 10 Mar 2015 14:16:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB4PR02CA0049.eurprd02.prod.outlook.com (10.242.174.177) To AMSPR07MB248.eurprd07.prod.outlook.com (10.242.19.27) Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB248; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(51704005)(87976001)(47776003)(62236002)(116806002)(44736004)(62966003)(50226001)(46102003)(2171001)(66066001)(92566002)(1556002)(76176999)(50986999)(81686999)(110136001)(81816999)(230783001)(14496001)(19580405001)(122386002)(23756003)(33646002)(44716002)(86362001)(19580395003)(77096005)(1456003)(40100003)(77156002)(84392001)(50466002)(61296003)(42186005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB248; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002009); SRVR:AMSPR07MB248; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB248; X-Forefront-PRVS: 051158ECBB X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2015 14:18:25.3048 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB248 Archived-At: Cc: iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-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: Tue, 10 Mar 2015 14:18:51 -0000 ----- Original Message ----- From: "Sam Hartman" To: "t.p." Cc: "Sam Hartman" ; ; ; ; Sent: Tuesday, March 10, 2015 12:48 PM > >>>>> "t" == t p writes: > > Well, I think you still need to answer questions like > > * Is it a fingerprint of the cert or the key? > > * Is the server expected to re-normalize the DER? Allowed to > re-normalize the DER? Sam Thank you for your comments. The I-D specifies fingerprint of the certificate so that is specified. Normalisation is not specified and is an interesting point; as you say, something to be considered. Tom Petch > So that the input to the hash is well specified. > Several protocols within the IETF have taken on the challenge of > describing how to fingerprint certificates. I think the document would > be improved by picking one of these strategies. > From nobody Wed Mar 11 00:16: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 39AAE1A912B; Wed, 11 Mar 2015 00:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 MiLIweo8OtvH; Wed, 11 Mar 2015 00:16:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B748E1A9073; Wed, 11 Mar 2015 00:16:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 895482DCC; Wed, 11 Mar 2015 08:16:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Q9y9UEY4Ac4C; Wed, 11 Mar 2015 08:15:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Mar 2015 08:16:00 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B85162003D; Wed, 11 Mar 2015 08:16:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JpQOVjb0Aue9; Wed, 11 Mar 2015 08:15:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 579D82003C; Wed, 11 Mar 2015 08:15:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 45F1A32769AF; Wed, 11 Mar 2015 08:15:59 +0100 (CET) Date: Wed, 11 Mar 2015 08:15:59 +0100 From: Juergen Schoenwaelder To: "t. p." Message-ID: <20150311071559.GC8717@elstar.local> Mail-Followup-To: "t. p." , Sam Hartman , ietf@ietf.org, secdir@ietf.org, iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org References: <006c01d05b3c$c44eac40$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006c01d05b3c$c44eac40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 07:16:04 -0000 On Tue, Mar 10, 2015 at 02:16:04PM +0000, t. p. wrote: > ----- Original Message ----- > From: "Sam Hartman" > To: "t.p." > Cc: "Sam Hartman" ; ; > ; ; > > Sent: Tuesday, March 10, 2015 12:48 PM > > >>>>> "t" == t p writes: > > > > Well, I think you still need to answer questions like > > > > * Is it a fingerprint of the cert or the key? > > > > * Is the server expected to re-normalize the DER? Allowed to > > re-normalize the DER? > > Sam > > Thank you for your comments. > > The I-D specifies fingerprint of the certificate so that is specified. > > Normalisation is not specified and is an interesting point; as you say, > something to be considered. > The model follows RFC 6353 (STD 78) and I am not aware of any issues that were reported against STD 78 because fingerprints do have issues with being ambiguous. So are we talking about a real-world problem or a problem that could exist in theory? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 11 04:52: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 28D751A6F27; Wed, 11 Mar 2015 04:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TY7rWL51r3Gr; Wed, 11 Mar 2015 04:37:13 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108341A00EA; Wed, 11 Mar 2015 04:37:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t2BBb8Ec019801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Mar 2015 11:37:08 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t2BBb5mo015965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 12:37:08 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0224.002; Wed, 11 Mar 2015 12:37:06 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "t.p." , Sam Hartman , "ietf@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: Secdir Review of draft-ietf-netconf-rfc5539bis-09 Thread-Index: AQHQW0n9mJmt5LFRvU2BKdI4qUhc050XKMHA Date: Wed, 11 Mar 2015 11:37:05 +0000 Message-ID: References: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> In-Reply-To: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2681 X-purgate-ID: 151667::1426073829-000067C4-B36833DA/0/0 Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 04:52:29 -0700 Cc: "draft-ietf-netconf-rfc5539bis.all@tools.ietf.org" Subject: Re: [secdir] Secdir Review of draft-ietf-netconf-rfc5539bis-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, 11 Mar 2015 11:37:15 -0000 -----Original Message----- From: t.p. [mailto:daedulus@btconnect.com]=20 Sent: Tuesday, March 10, 2015 1:12 PM To: Sam Hartman; ietf@ietf.org; secdir@ietf.org; iesg@ietf.org Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: Re: Secdir Review of draft-ietf-netconf-rfc5539bis-09 ----- Original Message ----- From: "Sam Hartman" To: ; ; Cc: Sent: Monday, March 09, 2015 12:10 PM Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09 > > This is an update to netconf over TLS with mutual X.509 authentication. > > In general, this looks fairly good. > > I'd ask the security ADs to take a look at two things: > > * The text on certificate validation in section 5. > Certificate validation has a number of options, none of which are > described or specified in this text. > Is that good enough for this application? (Probably) > > In section 7, there is a description of how the netconf server finds the > username of the client. > It talks about a certificate fingerprint without a reference to a > specific algorithm. > I'm aware of multiple algorithms for fingerprints. > This text is probably too vague for interoperability. Sam I see what you mean but had a different model in mind. The fingerprint is not transmitted as part of the tls/netconf protocol, I assume that it is only generated within a server when a certificate arrives over the tls/netconf protocol and is then compared with a prestored list of fingerprints within the server. So as long as the same algorithm is used within the server, then it does not matter what is used. If, instead, the prestored list of fingerprints is generated outside the server and installed as a file, then yes, the algorithm used to create the prestored list must be the same as that used within the server when a certificate arrives over the tls/netconf protocol. That is the only issue I can see. However, this I-D used to contain a data model to go with it but that has been put into a different I-D namely netconf-server. That data model imports a YANG data type tls-fingerprint which is defined as a one octet hashing algorithm identifier followed by the fingerprint value. The octet value is taken from the IANA TLS Hash Algorithm Registry (RFC 5246). So if the YANG data model is used, then the algorithm is part of the model and the server can look up what has been used in its prestored list of fingerprints. If users do not use the YANG data model, well that is up to them Hope this helps Tom Petch > From nobody Thu Mar 12 02:10: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 68BA91A1A22; Thu, 12 Mar 2015 02:10:08 -0700 (PDT) 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 iLnZgAgmrL7Z; Thu, 12 Mar 2015 02:10:06 -0700 (PDT) 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 12F451A8A04; Thu, 12 Mar 2015 02:10:05 -0700 (PDT) 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 t2C9A0q1011717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Mar 2015 11:10:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2C9A0J6029596; Thu, 12 Mar 2015 11:10:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21761.22504.139284.373056@fireball.kivinen.iki.fi> Date: Thu, 12 Mar 2015 11:10:00 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tram-stun-origin.all@tools.ietf.org X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-tram-stun-origin-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, 12 Mar 2015 09:10:08 -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 documents adds Origin attribute to the STUN that can be used in similar ways as the HTTP header field of the same name. The specified use cases include logging, analytincs and to provide additional information to the server in addition to the authentication mechanisms used. The draft notices that it can be set by attacker to any way, and can be modified in transit, and that it can also have privacy implications, so it should be protected using TLS or DTLS when needed. I think this draft is Ready. -- kivinen@iki.fi From nobody Thu Mar 12 03:16: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 25AFA1A90E8 for ; Thu, 12 Mar 2015 03:16:49 -0700 (PDT) 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 2XXo5nmV_Cq4 for ; Thu, 12 Mar 2015 03:16:47 -0700 (PDT) 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 EACC11A90DB for ; Thu, 12 Mar 2015 03:16:46 -0700 (PDT) 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 t2CAGgmW012612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Mar 2015 12:16:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2CAGg0E025127; Thu, 12 Mar 2015 12:16:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21761.26506.766556.161378@fireball.kivinen.iki.fi> Date: Thu, 12 Mar 2015 12:16:42 +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, 12 Mar 2015 10:16:49 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Chris Lonvick is next in the rotation. For telechat 2015-03-12 Reviewer LC end Draft Dave Cridland T 2015-02-18 draft-ietf-teas-lsp-attribute-ro-04 Dan Harkins T 2015-03-04 draft-ietf-dhc-dhcpv6-stateful-issues-11 Jeffrey Hutzelman T 2015-01-07 draft-ietf-dnssd-requirements-05 Chris Inacio T 2015-03-10 draft-ietf-pim-rfc4601bis-04 Melinda Shore T 2015-02-24 draft-faltstrom-uri-13 For telechat 2015-04-09 Tobias Gondrom T 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-04 Warren Kumari T 2015-04-07 draft-ietf-netext-pmip-qos-wifi-07 Matt Lepinski T 2015-04-02 draft-klensin-smtp-521code-05 Sam Weiler T 2015-02-16 draft-ietf-6man-resilient-rs-05 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Simon Josefsson 2015-03-18 draft-ietf-bess-mvpn-bidir-03 Benjamin Kaduk 2015-03-18 draft-ietf-ccamp-wson-signaling-10 Scott Kelly 2015-03-16 draft-ietf-sacm-use-cases-08 Ben Laurie 2015-03-23 draft-ietf-oauth-dyn-reg-management-09 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Fri Mar 13 09:21:51 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 A1EE51A9029; Fri, 13 Mar 2015 09:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1426263527; bh=ViHorO3wa8rhfsEzZ9AHAbSdrQe3TmiJPHbSf7LP/QQ=; 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=iuo1NpWlXs9iQSfEath/E2pWDWaavCz3B784XFkOzD+0iRLgFr8aLsgloRsUrdgbJ 0b2oNNVKorTURdASioNNArxt0sEVH38Zu4tJ5Au11yu4U1xbEjfWhDBrWF7ImqfTOf TkLU1JxAJ+v2Ol81wqQtUhTWO9Hm8VyZsrHJ+geQ= 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 E846E1A88C4; Fri, 13 Mar 2015 09:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVd6hYussTGO; Fri, 13 Mar 2015 09:18:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 452031A88E0; Fri, 13 Mar 2015 09:18:41 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150313161841.31261.67564.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 09:18:41 -0700 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, 13 Mar 2015 09:21:49 -0700 Subject: [secdir] [new-work] WG Review: TCP Maintenance and Minor Extensions (tcpm) 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, 13 Mar 2015 16:18:47 -0000 The TCP Maintenance and Minor Extensions (tcpm) working group in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-23. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------------ Current Status: Active WG Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Assigned Area Director: Martin Stiemerling Mailing list Address: tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/ Charter: TCP is currently the Internet's predominant transport protocol. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The focus of the working group is TCP. In cases where small changes are directly applicable to other transports (e.g., SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but other significant additions and changes to other transports are not in scope. TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control. In addition, TCPM may document alternative TCP congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet. Changes of algorithms may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Aug 2013 - Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC Nov 2013 - Submit document on TCP support for rate-limited traffic for publication (status decided as earlier milestone) Nov 2013 - Submit document on an analysis of more detailed ECN feedback in TCP to the IESG for publication as an Informational RFC Mar 2014 - Submit revision of TCP roadmap (RFC 4614) to the IESG for publication as an Informational RFC Mar 2015 - Submit document obsoleting undeployed TCP extensions to the IESG for publication as an Informational RFC Aug 2015 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Mar 15 17:53: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 8EE421A1EB7 for ; Sun, 15 Mar 2015 17:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHPT2Z813gf1 for ; Sun, 15 Mar 2015 17:52:59 -0700 (PDT) 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 8F05F1A1E0E for ; Sun, 15 Mar 2015 17:52:59 -0700 (PDT) Received: from smtp22.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp22.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id F204E1802E4; Sun, 15 Mar 2015 20:52:58 -0400 (EDT) Received: by smtp22.relay.ord1c.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 3326A180298; Sun, 15 Mar 2015 20:52:56 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from [172.30.10.81] ([UNAVAILABLE]. [211.217.127.195]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Mon, 16 Mar 2015 00:52:58 GMT From: Scott Kelly Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <22927F03-BF7B-45EC-A9F3-6E782C1366FA@hyperthought.com> Date: Mon, 16 Mar 2015 09:52:52 +0900 To: draft-ietf-sacm-use-cases.all@tools.ietf.org, secdir@ietf.org, iesg@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-sacm-use-cases-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, 16 Mar 2015 00:53:00 -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 informational document describes use cases for endpoint security = posture assessment. The security considerations section says that = specifics will be provided in related requirements, architecture, = protocol, etc. documents as appropriate. I see no issues with this document.= From nobody Mon Mar 16 13:41: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 563401A90E0; Mon, 16 Mar 2015 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RBAtxX9MMALM; Mon, 16 Mar 2015 13:40:59 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFA31A90D8; Mon, 16 Mar 2015 13:40:59 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2EC0E1FE01EA; Mon, 16 Mar 2015 13:40:59 -0700 (PDT) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 16 Mar 2015 13:40:59 -0700 (PDT) Message-ID: Date: Mon, 16 Mar 2015 13:40:59 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv6-stateful-issues.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-dhc-dhcpv6-stateful-issues=11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 20:41:00 -0000 First of all, sorry for the tardiness of this review…. 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 quite a few updates to RFC 3315 to deal with an issue that was not anticipated when that RFC was developed: additional stateful DHCPv6 options. The problematic option that has been added is for DHCPv6 prefix delegation (IA_PD) and some interop issues have been observed when the non-temporary addresses option (IA_NA) and the prefix delegation option are used together. The draft specifies new normative behavior to address coexistence problems with IA_NA and IA_PD. I believe the draft is "Ready with nits". Actually ready with nit and that nit is that the Security Considerations should point back to RFC 3315 (which has nice Security Considerations). Currently it only says, "There are no new security considerations pertaining to this document." and it might be a good idea to say something more like "This document adds no new security considerations to those described in [RFC 3315]." or something like that. regards, Dan. From nobody Tue Mar 17 10: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 BCB8A1A87C9 for ; Tue, 17 Mar 2015 10:18:20 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] 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 Y5czAlEaUJp8 for ; Tue, 17 Mar 2015 10:18:18 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F851A87D4 for ; Tue, 17 Mar 2015 10:18:17 -0700 (PDT) Received: by webcq43 with SMTP id cq43so12924551web.2 for ; Tue, 17 Mar 2015 10:18:16 -0700 (PDT) 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=BA7L2Kj3inu9v7D+b91Adl+xbyIB2rNw7KWwmmPn4sA=; b=Dk/Eno/GM4lumHNz8DVwX4ztfYrDAgwO2ZHeNqAiHFGykafX1/JSCUJ4P3Ny54AL1n YAZyStyOwSFEpFWUdRKPJWGvEr7Mqplkcc65G9KMn7juj6rOXJ7nGYPTyUdELlrICyjn 7m8G4ah2nKfeN6dmysHjmk9mpz2F+LRj+haznyCdcqz6pQovQ5b7NG6Yx3AuIgcXhqER ywuH9Puw8A4UZlhUgv5upA1ZTtzZwMSQfQ69++W13kGfJr2BJqedcJ2AZTZRk3qQAB7U xo1SyFL5mVieYY/GkCEVhsFBkfDibWf2hjf4Fp31qy7J0nDrr+TPTi1eefWHj+9Fc+5u Rjzg== X-Gm-Message-State: ALoCoQkQ3LRYVnhzCtFO7tjX44Of/hDl9VsDsc7VF8eba0YtBrppSNgxwBsw3WyUqVyXwK06DAWf MIME-Version: 1.0 X-Received: by 10.194.221.100 with SMTP id qd4mr131819160wjc.113.1426612696286; Tue, 17 Mar 2015 10:18:16 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Tue, 17 Mar 2015 10:18:16 -0700 (PDT) Date: Tue, 17 Mar 2015 13:18:16 -0400 Message-ID: From: Warren Kumari To: draft-ietf-sacm-use-cases.all@tools.ietf.org, "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-sacm-use-cases 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, 17 Mar 2015 17:18:20 -0000 Be ye not afraid! 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 with grammar nits. Document reviewed:draft-ietf-sacm-use-cases-08.txt Note: This is Endpoint Security Posture Assessment - Enterprise Use Cases As a use case, it mainly provides justification for SACM work, and example use cases. This is useful, but there is not much meat for a security review. One thing that the document could mention (although this could easily be done in some other document) is that a malicious party could use this collected data to help him figure out which end points are not as well protected, and so make his reconnoissance easier. Nits and such: The word "Optional" in Section 2.2.5. makes the nit checker confused is in square brackets ( "[]" ) -- this makes the nit checker assume it is a reference and so it complains. This can easily be ignored, but I suspect other tools might also become confused - it may be a good idea to wrap it in some other set of quating instead. More nits: 1. Introduction .... Togther these ideas will be used to guide development of vendor- [O] Togther [P] Together [R] spelling .... It is expected that use cases for enterprises and for service providers will largely overlap, but there are additional [O] will largely overlap, but there are additional [P] will largely overlap. But there are additional [R] readability 2. Endpoint Posture Assessment .... o Making the attributes available for evaluation and action; and o Verifying that the endpoint's posture is in compliance with enterprise standards and policy. As part of these activities it is often necessary to identify and [O] As part of these activities it is often necessary [P] As part of these activities, it is often necessary [R] Readability .... 2.1.1. Define, Publish, Query and Retrieve Security Automation Data .... * Policies that define how to target and perform the evaluation of a set of attributes for different kinds or groups of endpoints and the assets they are composed of. In some cases it may be desirable to maintain hierarchies of policies as well. * References to human oriented-data that provide technical, [O] human oriented-data [P] human-oriented data [R] correction organizational, and/or policy context. This might include references to: best practices documents, legal guidance and legislation, and instructional materials related to the automation data in question. ..... * Organizationally defined expected posture attribute values targeted to specific evaluation guidance and endpoint characteristics. This allows a common set of guidance to be parameterized for use with different groups of endpoints. Processing Artifacts: Data that is generated by and is specific to [O] that is generated by and is specific to [P] that is generated by, and is specific to, [R] readability an individual assessment process. This data may be used as part of the interactions between architectural components to drive and coordinate collection and evaluation activities. Its lifespan will be bounded by the lifespan of the assessment. It may also be exchanged and stored to provide historic context around an assessment activity so that individual assessments can be grouped, evaluated, and reported in an enterprise context. .... Data Definition: Security automation data will guide and inform collection and evaluation processes. This data may be designed by a variety of roles - application implementers may build security automation data into their applications; administrators may define guidance based on organizational policies; operators may define guidance and attribute data as needed for evaluation at runtime, and so on. Data producers may choose to reuse data from existing stores of security automation data and may create new data. Data producers may [O]data and may create new data [P] data and/or may create new data [R] I think this is what is meant? Not sure if the "create new data" would be from the existing stores of data. develop data based on available standardized or proprietary data models, such as those used for network management and/or host management. ... Data Retrieval: An user, operator, or application acquires one or [O] An user [P] A user [R] Grammar more specific security automation data entries. The location of the data may be known a priori, or may be determined based on decisions made using information from a previous query. 2.1.4. Posture Attribute Evaluation ... While the primary focus of this use cases is around enabling the [O] this use cases [P] this use case [R] grammar comparison of expected vs. actual state, the same building blocks can support other analysis techniques that are applied to collected posture attribute data (e.g., trending, historic analysis). ... 2.2.1. Definition and Publication of Automatable Configuration Checklists ... Each guide they produce applies to a specific model of device and version of the operating system and provides a number of specialized configurations depending on the devices intended function and what [O] on the devices intended function [P] on the device's intended function [R] grammar (possessive, not plural) add-on hardware modules and software licenses are installed on the device. To enable their customers to evaluate the security posture of their devices to ensure that all appropriate minimal security settings are enabled, they publish an automatable configuration checklists using a popular data format that defines what settings to collect using a network management protocol and appropriate values for each setting. They publish these checklist to a public security [O] these checklist to [P] these checklists to [R] grammar automation data store that customers can query to retrieve applicable checklist for their deployed specialized endpoint devices. [O] checklist for their deployed [P] checklist(s) for their deployed [R] grammar Automatable configuration checklist could also come from sources other than a device vendor, such as industry groups or regulatory authorities, or enterprises could develop their own checklists. This usage scenario employs the following building blocks defined in Section 2.1.1 above: Data Definition: To allow guidance to be defined using standardized or proprietary data models that will drive Collection and Evaluation. [O] Collection and Evaluation. [P] collection and evaluation. [R] no reason to capitalize... Data Publication: Providing a mechanism to publish created guidance to a security automation data store. Data Query: To locate and select existing guidance that may be reused. ... 2.2.2. Automated Checklist Verification ... The results of checklist evaluation are provided to appropriate operators and applications to drive additional business logic. Specific applications for checklist evaluation results are out-of- scope for current SACM efforts. Irrespective of specific applications, the availability, timeliness, and liveness of results is often of general concern. Network latency and available bandwidth often create operational constriants that require trade-offs between [O] constriants [P] contraints [R] spelling these concerns and need to be considered. ... Posture Attribute Evaluation: The resulting posture attribute values from previous Collection processes are evaluated using the [O] Collection [P] collection [R] not sure why it's capitalized; maybe a typo? evaluation guidance to provide a set of posture results. 2.2.3. Detection of Posture Deviations ... When a change occurs to posture defined in the baseline, updated posture information is exchanged allowing operators to be notified and/or automated action [O] is exchanged allowing operators [P] is exchanged, allowing operators [R] grammar to be taken. ... 2.2.5. Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra A university team receives a grant to do research at a government facility in the arctic. The only network communications will be via an intermittent low-speed high-latency high-cost satellite link. [O] intermittent low-speed high-latency high-cost [P] intermittent, low speed, high latency, high cost [R] grammar/readability During their extended expedition they will need to show continue [O] During their extended expedition they will [P] During their extended expedition, they will [R] grammar compliance with the security policies of the university, the government, and the provider of the satellite network as well as keep current on vulnerability testing. Interactive assessments are therefore not reliable, and since the researchers have very limited funding they need to minimize how much money they spend on network data. .... In the case of new critical vulnerabilities this collection request [O] In the case of new critical vulnerabilities this collection request [P] In the case of new critical vulnerabilities, this collection request [R] grammar consists only of the artifacts necessary for those vulnerabilities and collection is only initiated for those assets that could potentially have a new vulnerability. [Optional] Asset artifacts are cached in a local CMDB. When new vulnerabilities are reported to the security automation data store, a request to the live asset is only done if the artifacts in the CMDB are incomplete and/or not current enough. ... The collected artifacts eventually make it back to the university where the level of compliance and vulnerability expose is calculated [O] level of compliance and vulnerability expose [P] level of compliance and vulnerability exposed [R] grammar and asset characteristics are compared to what is in the asset management system for accuracy and completeness. ... 4. Security Considerations This memo documents, for Informational purposes, use cases for [O] for Informational purposes [P] for informational purposes [R] not sure "informational" is capitalized. security automation. Specific security considerations will be provided in related documents (e.g., requirements, architecture, information model, data model, protocol) as appropriate to the function described in each related document. ------------- W -- 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 Tue Mar 17 13:09: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 E4A541A88D5; Tue, 17 Mar 2015 13:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 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] 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 Xo11LtR-Kp4r; Tue, 17 Mar 2015 13:08:54 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520E51A88CF; Tue, 17 Mar 2015 13:08:51 -0700 (PDT) X-AuditID: 12074425-f79846d0000054e1-3c-550889d15c8d 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 88.C3.21729.2D988055; Tue, 17 Mar 2015 16:08:50 -0400 (EDT) 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 t2HK8npq011944; Tue, 17 Mar 2015 16:08:49 -0400 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 t2HK8kW4017550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Mar 2015 16:08:48 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2HK8kvG020791; Tue, 17 Mar 2015 16:08:46 -0400 (EDT) Date: Tue, 17 Mar 2015 16:08:46 -0400 (EDT) From: Benjamin Kaduk To: ietf@ietf.org, secdir@ietf.org, draft-ietf-ccamp-wson-signaling.all@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+NgFjrBIsWRmVeSWpSXmKPExsUixCmqrHupkyPUYM4EFovtd7wsnm2cz2Lx YeFDFgdmjyVLfjIFMEZx2aSk5mSWpRbp2yVwZfTNOsxUMF2iYtucVawNjEeFuxg5OSQETCTW dLYyQthiEhfurWfrYuTiEBJYzCSxrKuFCcLZyCjx7O41VgjnEJNEw8wORgingVFi1qRuoB4O DhYBbYktrQ4go9gEVCRmvtnIBmKLCERKPPu5CmyFsICDxOPFt8BsXiD74JZJLCC2qICOxOr9 U1gg4oISJ2c+AbOZBbQklk/fxjKBkW8WktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKL dC30cjNL9FJTSjcxggKM3UV1B+OEQ0qHGAU4GJV4eG8UsIcKsSaWFVfmHmKU5GBSEuVlzeUI FeJLyk+pzEgszogvKs1JLT7EKMHBrCTCq9UClONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliS mp2aWpBaBJOV4eBQkuB92AHUKFiUmp5akZaZU4KQZuLgBBnOAzRcthNkeHFBYm5xZjpE/hSj opQ4Lz9IQgAkkVGaB9cLSwCvGMWBXhHm/QWyggeYPOC6XwENZgIa3NLOBjK4JBEhJdXAyPeR J6t4v7rxj7hsczt2ybwPW8pqKo8UXeU+dljN8tr5I7Y7rJtVzC4qPI571p29zas4Z/va5I0S bDrNlWyPHbdbPLu4TtHkv52Uu5P0dh0e/Vea0+7qvX3SceJk1IxbV89dbmlLmjSFrVWocMX3 fuaZPWn7Lpw44pmpsStY+6Fic9wtyStmSizFGYmGWsxFxYkAuCClRdsCAAA= Archived-At: Subject: [secdir] secdir review of draft-ietf-ccamp-wson-signaling-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 20:08:57 -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. I think this document is ready with nits. The security considerations notes that this is a simple extension to existing mechanisms and is not carrying qualitatively different information compared to the existing specifications. The security considerations of RFC 3473, and RFC 5920, seem to provide adequate treatment of the security issues at play here. The nits are largely editorial in nature: The list of WSON Signal Characteristics introduces the acronym FEC and includes its expansion in the body, but does not explicitly define the term. That could be done in the Terminology section. In section 3.2, the term "3R regeneration" is used, but it is not mentioned in the Temrinology section. (As not a routing person, I had to look it up.) In section 4.1, I think that an "in the" or "by the" (or similar) is missing prior to "Generalized Label Request object". Section 4.2 claims that the requirements for signaling to indicate to a particular node what type of processing to perform are given in section 3.2, however, I see no such requirements in section 3.2; is a different section intended? Also in section 4.2, the term "WSON Processing HOP Attribute TLV" is used. Is HOP an acronym? I do not see it in the RFC Editor's list of abbreviations (https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) and I am not entirely sure that I understand its meaning. The artwork for the contents of that TLV immediately follows. The subsequent descriptive text indicates that there may be padding after the 'Value' field, to align the end of the record to a four-octet boundary. It might be useful to include some padding in the artwork. The text description for the "Length" field says that the included length is four plus the length of the value field in octets, but the artwork has only one octet for each of the Type and Length fields, which would make the constant two, not four. (Perhaps those two fields were changed from two octets to one octet in some revision of the document?) Likewise, the description of the WavelengthSelection sub-TLV in the table with Name/Type/Length indicates that 3 octets of padding would be needed after the 1 octet of 'Value' contents. However, if the Type and Length fields are only one octet each, only one octet of padding would be needed, not three. In section 4.2.1, it is said that "No more than two ResourceBlockInfo sub-TLVs SHOULD be present." However, the RBNF for the WSON Processing HOP Attribute allows at most two, so any more than two would be noncompliant with the RBNF. It is unclear to me if this incongruity is actually a cause for concern; it probably depends on why SHOULD is used instead of MUST. -Ben Kaduk From nobody Wed Mar 18 22:53:58 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 967651A893B; Wed, 18 Mar 2015 22:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 QtXGH7yba2o3; Wed, 18 Mar 2015 22:53:55 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 EF1D81A007D; Wed, 18 Mar 2015 22:53:54 -0700 (PDT) Received: from latte.josefsson.org ([217.31.163.140]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t2J5rlQC028753 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 19 Mar 2015 06:53:51 +0100 Date: Thu, 19 Mar 2015 06:53:41 +0100 From: Simon Josefsson To: secdir@ietf.org, draft-ietf-bess-mvpn-bidir.all@ietf.org Message-ID: <20150319065341.3d7d3f5b@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/bTt_OT3mxL_ZAT0zZPCus.Y"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.6 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [secdir] Rewiew of draft-ietf-bess-mvpn-bidir 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, 19 Mar 2015 05:53:56 -0000 --Sig_/bTt_OT3mxL_ZAT0zZPCus.Y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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 follows up on earlier RFCs and describe how to do multicast in BGP/MPLS IP VPN/tunnels, which were underspecified earlier. I believe the document is ready. Multicast in tunnels can have security considerations, but this RFC does not introduce the concept. It refers to earlier RFCs that introduce the concept and contain the security considerations. I don't feel that this RFC introduce particular important new concepts to warrant a more extensive security considerations. I have a general security caveat with all things in the MPLS/routing world: the specifications are large (hence slight delay of this review as it interfered with skiing) and are dense to read due to the large amount of acronyms used. This is a real challenge for anyone who wants to analyze security properties of the protocols or deployments. /Simon --Sig_/bTt_OT3mxL_ZAT0zZPCus.Y Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVCmRlAAoJEIYLf7sy+BGdOR0H/jQdCV97OiqNnlxj/KA366xX r/6N1+N6UXHtJ0vhLxJElQQpN039oTJ0swkBy0VKSSlz4dt+kw5rDafhX6S13BA2 8OHusrcz1jHI6FxQ6sQ2tjcKCKnKWYFfZvx1+/nHE/FNep+wAGXvMk00PZvVcaDC 4IqcZspBDTm/8nHom0vZMg6HjxFFJ52LI2L3SO5BbuC4rI0WgHi8GMxI9s7QTG2f 5oVMnckSDctiob5BgYJyII6ArajAF6gcE9Pb0KdSG6oETyIzUNKNW7nbKm64TVPc yfhCTyGDk8NrU5tXrLuoDPuiQ7Kq+I49jfhU3Lhz7jmzV6Xa/yNucA89hyU90qQ= =qLDF -----END PGP SIGNATURE----- --Sig_/bTt_OT3mxL_ZAT0zZPCus.Y-- From nobody Thu Mar 19 03:31: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 184E81A87E4 for ; Thu, 19 Mar 2015 03:31:46 -0700 (PDT) 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 XlobDYjXGsSE for ; Thu, 19 Mar 2015 03:31:44 -0700 (PDT) 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 F0D4A1A876C for ; Thu, 19 Mar 2015 03:31:43 -0700 (PDT) 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 t2JAVe3r010561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 19 Mar 2015 12:31:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2JAVen1019909; Thu, 19 Mar 2015 12:31:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21770.42380.697907.244085@fireball.kivinen.iki.fi> Date: Thu, 19 Mar 2015 12:31:40 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 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, 19 Mar 2015 10:31:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yoav Nir is next in the rotation. For telechat 2015-04-09 Reviewer LC end Draft Tobias Gondrom T 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-04 Warren Kumari T 2015-04-07 draft-ietf-netext-pmip-qos-wifi-07 Ben Laurie T 2015-03-23 draft-ietf-oauth-dyn-reg-management-09 Matt Lepinski T 2015-04-02 draft-klensin-smtp-521code-05 Chris Lonvick T 2015-04-06 draft-ietf-appsawg-multipart-form-data-08 Catherine Meadows T 2015-04-02 draft-ietf-httpbis-auth-info-04 Sam Weiler T 2015-02-16 draft-ietf-6man-resilient-rs-05 Brian Weis TR2015-03-20 draft-ietf-radext-dynamic-discovery-13 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Alexey Melnikov 2015-04-08 draft-ietf-idr-flowspec-redirect-rt-bis-03 Matthew Miller 2015-04-08 draft-ietf-idr-ls-distribution-10 Adam Montville 2015-04-08 draft-ietf-isis-extended-sequence-no-tlv-04 Sandy Murphy 2015-03-30 draft-ietf-tls-sslv3-diediedie-02 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Mon Mar 23 15:11:32 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 2D9401B2AC3 for ; Mon, 23 Mar 2015 15:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o8RBkYkyBzFd for ; Mon, 23 Mar 2015 15:11:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F36E1B2AC6 for ; Mon, 23 Mar 2015 15:11:26 -0700 (PDT) Received: from DM2PR09MB0365.namprd09.prod.outlook.com (25.160.247.18) by DM2PR09MB0366.namprd09.prod.outlook.com (25.160.247.20) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 23 Mar 2015 22:11:09 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([25.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([25.160.247.18]) with mapi id 15.01.0118.021; Mon, 23 Mar 2015 22:11:09 +0000 From: "Waltermire, David A." To: Warren Kumari Thread-Topic: [secdir] Secdir review of draft-ietf-sacm-use-cases Thread-Index: AQHQYNZhacmgDj5e/0u1Lekv9TkIi50qp65w Date: Mon, 23 Mar 2015 22:11:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.223.75] authentication-results: kumari.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0366; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(99286002)(40100003)(106116001)(19580395003)(19580405001)(66066001)(110136001)(92566002)(1720100001)(2656002)(77156002)(2900100001)(46102003)(102836002)(76176999)(76576001)(230783001)(15975445007)(86362001)(74316001)(2950100001)(62966003)(33656002)(87936001)(50986999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0366; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DM2PR09MB0366; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0366; x-forefront-prvs: 05245CA661 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2015 22:11:09.3528 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0366 Archived-At: Cc: "draft-ietf-sacm-use-cases.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-sacm-use-cases 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, 23 Mar 2015 22:11:31 -0000 Warren, I have accepted and addressed all your nits and will be posting an updated = draft with these changes soon. You also pointed out that it would be valuable to mention in the security c= onsiderations "that a malicious party could use this collected data to help= him figure out which end points are not as well protected, and so make his= reconnaissance easier." We have been working on the following text to address this issue: One consideration for security automation is that a malicious actor could u= se the security automation infrastructure and related collected data to det= ermine endpoint weaknesses to exploit. It is important that security cons= iderations in the related documents identify methods to both identify and p= revent such activity. Specifically, means for protecting the communication= s as well as the systems that store the information. For communications be= tween the varying SACM components there should be considerations for protec= ting the confidentiality, data integrity and peer entity authentication. = Also, for any systems that store information that could be used for malicio= us purposes, methods to identify and protect against unauthorized usage, in= appropriate usage and denial of service need to be considered. Does this text address your concern? If so, I'll post the updated draft containing this and the other requested = changes. Thanks, Dave -----Original Message----- From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Tuesday, March 17, 2015 1:18 PM To: draft-ietf-sacm-use-cases.all@tools.ietf.org; secdir@ietf.org Subject: [secdir] Secdir review of draft-ietf-sacm-use-cases Be ye not afraid! I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: Ready with grammar nits. Document reviewed:draft-ietf-sacm-use-cases-08.txt Note: This is Endpoint Security Posture Assessment - Enterprise Use Cases A= s a use case, it mainly provides justification for SACM work, and example u= se cases. This is useful, but there is not much meat for a security review. One thing that the document could mention (although this could easily be do= ne in some other document) is that a malicious party could use this collect= ed data to help him figure out which end points are not as well protected, = and so make his reconnoissance easier. Nits and such: The word "Optional" in Section 2.2.5. makes the nit checker confused is in = square brackets ( "[]" ) -- this makes the nit checker assume it is a refer= ence and so it complains. This can easily be ignored, but I suspect other t= ools might also become confused - it may be a good idea to wrap it in some = other set of quating instead. More nits: 1. Introduction .... Togther these ideas will be used to guide development of vendor- [O] Togther [P] Together [R] spelling .... It is expected that use cases for enterprises and for service providers will largely overlap, but there are additional [O] will largely overlap, but there are additional [P] will largely overla= p. But there are additional [R] readability 2. Endpoint Posture Assessment .... o Making the attributes available for evaluation and action; and o Verifying that the endpoint's posture is in compliance with enterprise standards and policy. As part of these activities it is often necessary to identify and [O] As part of these activities it is often necessary [P] As part of these = activities, it is often necessary [R] Readability .... 2.1.1. Define, Publish, Query and Retrieve Security Automation Data .... * Policies that define how to target and perform the evaluation of a set of attributes for different kinds or groups of endpoints and the assets they are composed of. In some cases it may be desirable to maintain hierarchies of policies as well. * References to human oriented-data that provide technical, [O] human oriented-data [P] human-oriented data [R] correction organizational, and/or policy context. This might include references to: best practices documents, legal guidance and legislation, and instructional materials related to the automation data in question. ..... * Organizationally defined expected posture attribute values targeted to specific evaluation guidance and endpoint characteristics. This allows a common set of guidance to be parameterized for use with different groups of endpoints. Processing Artifacts: Data that is generated by and is specific to [O] = that is generated by and is specific to [P] that is generated by, and is sp= ecific to, [R] readability an individual assessment process. This data may be used as part of the interactions between architectural components to drive and coordinate collection and evaluation activities. Its lifespan will be bounded by the lifespan of the assessment. It may also be exchanged and stored to provide historic context around an assessment activity so that individual assessments can be grouped, evaluated, and reported in an enterprise context. .... Data Definition: Security automation data will guide and inform collection and evaluation processes. This data may be designed by a variety of roles - application implementers may build security automation data into their applications; administrators may define guidance based on organizational policies; operators may define guidance and attribute data as needed for evaluation at runtime, and so on. Data producers may choose to reuse data from existing stores of security automation data and may create new data. Data producers may [O]data and may create new data [P] data and/or may create new data [R] I think this is what is meant? Not sure if the "create new data" would be from the existing stores of data. develop data based on available standardized or proprietary data models, such as those used for network management and/or host management. ... Data Retrieval: An user, operator, or application acquires one or [O] An user [P] A user [R] Grammar more specific security automation data entries. The location of the data may be known a priori, or may be determined based on decisions made using information from a previous query. 2.1.4. Posture Attribute Evaluation ... While the primary focus of this use cases is around enabling the [O] this use cases [P] this use case [R] grammar comparison of expected vs. actual state, the same building blocks can support other analysis techniques that are applied to collected posture attribute data (e.g., trending, historic analysis). ... 2.2.1. Definition and Publication of Automatable Configuration Checklists ... Each guide they produce applies to a specific model of device and version of the operating system and provides a number of specialized configurations depending on the devices intended function and what [O] o= n the devices intended function [P] on the device's intended function [R] g= rammar (possessive, not plural) add-on hardware modules and software licenses are installed on the device. To enable their customers to evaluate the security posture of their devices to ensure that all appropriate minimal security settings are enabled, they publish an automatable configuration checklists using a popular data format that defines what settings to collect using a network management protocol and appropriate values for each setting. They publish these checklist to a public security [O] these checklist to [P] these checklists to [R] grammar automation data store that customers can query to retrieve applicable checklist for their deployed specialized endpoint devices. [O] checklist for their deployed [P] checklist(s) for their deployed [R] grammar Automatable configuration checklist could also come from sources other than a device vendor, such as industry groups or regulatory authorities, or enterprises could develop their own checklists. This usage scenario employs the following building blocks defined in Section 2.1.1 above: Data Definition: To allow guidance to be defined using standardized or proprietary data models that will drive Collection and Evaluation. [O] Collection and Evaluation. [P] collection and evaluation. [R] no reason to capitalize... Data Publication: Providing a mechanism to publish created guidance to a security automation data store. Data Query: To locate and select existing guidance that may be reused. ... 2.2.2. Automated Checklist Verification ... The results of checklist evaluation are provided to appropriate operators and applications to drive additional business logic. Specific applications for checklist evaluation results are out-of- scope for current SACM efforts. Irrespective of specific applications, the availability, timeliness, and liveness of results is often of general concern. Network latency and available bandwidth often create operational constriants that require trade-offs between [O] constriants [P] contraints [R] spelling these concerns and need to be considered. ... Posture Attribute Evaluation: The resulting posture attribute values from previous Collection processes are evaluated using the [O] Collection [P] collection [R] not sure why it's capitalized; maybe a typo? evaluation guidance to provide a set of posture results. 2.2.3. Detection of Posture Deviations ... When a change occurs to posture defined in the baseline, updated posture information is exchanged allowing operators to be notified and/or automated action [O] is exchanged allowing operators [P] is exchanged, allowing operators [R] grammar to be taken. ... 2.2.5. Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra A university team receives a grant to do research at a government facility in the arctic. The only network communications will be via an intermittent low-speed high-latency high-cost satellite link. [O] intermittent low-speed high-latency high-cost [P] intermittent, low spe= ed, high latency, high cost [R] grammar/readability During their extended expedition they will need to show continue [O] During their extended expedition they will [P] During their extended ex= pedition, they will [R] grammar compliance with the security policies of the university, the government, and the provider of the satellite network as well as keep current on vulnerability testing. Interactive assessments are therefore not reliable, and since the researchers have very limited funding they need to minimize how much money they spend on network data. .... In the case of new critical vulnerabilities this collection request [O] In the case of new critical vulnerabilities this collection request [P]= In the case of new critical vulnerabilities, this collection request [R] g= rammar consists only of the artifacts necessary for those vulnerabilities and collection is only initiated for those assets that could potentially have a new vulnerability. [Optional] Asset artifacts are cached in a local CMDB. When new vulnerabilities are reported to the security automation data store, a request to the live asset is only done if the artifacts in the CMDB are incomplete and/or not current enough. ... The collected artifacts eventually make it back to the university where the level of compliance and vulnerability expose is calculated [O] level of compliance and vulnerability expose [P] level of compliance an= d vulnerability exposed [R] grammar and asset characteristics are compared to what is in the asset management system for accuracy and completeness. ... 4. Security Considerations This memo documents, for Informational purposes, use cases for [O] for Informational purposes [P] for informational purposes [R] not sure "informational" is capitalized. security automation. Specific security considerations will be provided in related documents (e.g., requirements, architecture, information model, data model, protocol) as appropriate to the function described in each related document. ------------- W -- 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 regr= et at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon Mar 23 17:52: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 740471ACDD5 for ; Mon, 23 Mar 2015 17:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 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] 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 kT7yjy6KKNl9 for ; Mon, 23 Mar 2015 17:52:12 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4251AC3DF for ; Mon, 23 Mar 2015 17:52:11 -0700 (PDT) Received: by wixw10 with SMTP id w10so79720622wix.0 for ; Mon, 23 Mar 2015 17:52:10 -0700 (PDT) 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=zwRqWP69KDB+sMkzT75v6ImooHWyxNbrE+srjkYg4P8=; b=MXcznFb02fB4eXw+kBX7O+7gLg+j1Tj3+dCx5eWiMYE2f9Dfb/lUMXMKTvJWNWBKBv xQxgcgYJGLLwf8i+x5AN9RpkVkRcghUJcGTdTTjlgL0H3LNPPWO3dogA5kTfVMz7GHLp 5IpQGQynsi0RXgRQNfOignDauQUMRVKQ2nHKMCP0kBY09VpVSYpRv97CDhly5BD7ovUz l50WYTWur+SR89rwV1CBknpHtYq4bTAcU7ZqFH93EXi3TRincUDjiRjBq5aC1BzGRdpR zi0xNKOhaoUkQjuWw9o1MKLLuM+/b22rIsFaAo6ZtkQnanEuumcXZKNkFZWSI0eacHvg duDg== X-Gm-Message-State: ALoCoQnOo2CKsCdTcLPtLRFKb5vlXpnNOFFKcHn+dO48JDx0adsxU/ScEWCaK9HT+vRmIaF0fMqq MIME-Version: 1.0 X-Received: by 10.194.221.100 with SMTP id qd4mr2751207wjc.113.1427158330305; Mon, 23 Mar 2015 17:52:10 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Mon, 23 Mar 2015 17:52:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 19:52:10 -0500 Message-ID: From: Warren Kumari To: "Waltermire, David A." Content-Type: multipart/alternative; boundary=001a11c3aa745105f60511fe3197 Archived-At: Cc: "draft-ietf-sacm-use-cases.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-sacm-use-cases 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, 24 Mar 2015 00:52:17 -0000 --001a11c3aa745105f60511fe3197 Content-Type: text/plain; charset=UTF-8 On Monday, March 23, 2015, Waltermire, David A. wrote: > Warren, > > I have accepted and addressed all your nits and will be posting an updated > draft with these changes soon. > > You also pointed out that it would be valuable to mention in the security > considerations "that a malicious party could use this collected data to > help him figure out which end points are not as well protected, and so make > his reconnaissance easier." > > We have been working on the following text to address this issue: > > One consideration for security automation is that a malicious actor could > use the security automation infrastructure and related collected data to > determine endpoint weaknesses to exploit. It is important that security > considerations in the related documents identify methods to both identify > and prevent such activity. Specifically, means for protecting the > communications as well as the systems that store the information. For > communications between the varying SACM components there should be > considerations for protecting the confidentiality, data integrity and peer > entity authentication. Also, for any systems that store information that > could be used for malicious purposes, methods to identify and protect > against unauthorized usage, inappropriate usage and denial of service need > to be considered. > > Does this text address your concern? Yup. Looks really good. W > > If so, I'll post the updated draft containing this and the other requested > changes. > > Thanks, > Dave > > -----Original Message----- > From: secdir [mailto:secdir-bounces@ietf.org ] On Behalf Of > Warren Kumari > Sent: Tuesday, March 17, 2015 1:18 PM > To: draft-ietf-sacm-use-cases.all@tools.ietf.org ; > secdir@ietf.org > Subject: [secdir] Secdir review of draft-ietf-sacm-use-cases > > Be ye not afraid! > > 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 with grammar nits. > > Document reviewed:draft-ietf-sacm-use-cases-08.txt > > Note: This is Endpoint Security Posture Assessment - Enterprise Use Cases > As a use case, it mainly provides justification for SACM work, and example > use cases. This is useful, but there is not much meat for a security review. > > One thing that the document could mention (although this could easily be > done in some other document) is that a malicious party could use this > collected data to help him figure out which end points are not as well > protected, and so make his reconnoissance easier. > > Nits and such: > The word "Optional" in Section 2.2.5. makes the nit checker confused is in > square brackets ( "[]" ) -- this makes the nit checker assume it is a > reference and so it complains. This can easily be ignored, but I suspect > other tools might also become confused - it may be a good idea to wrap it > in some other set of quating instead. > > More nits: > > > > 1. Introduction > > .... > > Togther these ideas will be used to guide development of vendor- > > [O] Togther > [P] Together > [R] spelling > > .... > It is expected that use cases for enterprises and for service > providers will largely overlap, but there are additional > > [O] will largely overlap, but there are additional [P] will largely > overlap. But there are additional [R] readability > > > > 2. Endpoint Posture Assessment > > .... > > o Making the attributes available for evaluation and action; and > > o Verifying that the endpoint's posture is in compliance with > enterprise standards and policy. > > As part of these activities it is often necessary to identify and > > [O] As part of these activities it is often necessary [P] As part of these > activities, it is often necessary [R] Readability > > .... > > 2.1.1. Define, Publish, Query and Retrieve Security Automation Data > > .... > * Policies that define how to target and perform the > evaluation of a set of attributes for different kinds or > groups of endpoints and the assets they are composed of. In > some cases it may be desirable to maintain hierarchies of > policies as well. > > * References to human oriented-data that provide technical, > > [O] human oriented-data > [P] human-oriented data > [R] correction > > organizational, and/or policy context. This might include > references to: best practices documents, legal guidance and > legislation, and instructional materials related to the > automation data in question. > ..... > > * Organizationally defined expected posture attribute values > targeted to specific evaluation guidance and endpoint > characteristics. This allows a common set of guidance to be > parameterized for use with different groups of endpoints. > > Processing Artifacts: Data that is generated by and is specific to [O] > that is generated by and is specific to [P] that is generated by, and is > specific to, [R] readability > > an individual assessment process. This data may be used as > part of the interactions between architectural components to > drive and coordinate collection and evaluation activities. Its > lifespan will be bounded by the lifespan of the assessment. It > may also be exchanged and stored to provide historic context > around an assessment activity so that individual assessments > can be grouped, evaluated, and reported in an enterprise > context. > > .... > > Data Definition: Security automation data will guide and inform > collection and evaluation processes. This data may be designed > by a variety of roles - application implementers may build > security automation data into their applications; > administrators may define guidance based on organizational > policies; operators may define guidance and attribute data as > needed for evaluation at runtime, and so on. Data producers > may choose to reuse data from existing stores of security > automation data and may create new data. Data producers may > > [O]data and may create new data > [P] data and/or may create new data > [R] I think this is what is meant? Not sure if the "create new data" > would be from the existing stores of data. > > develop data based on available standardized or proprietary > data models, such as those used for network management and/or > host management. > > ... > > Data Retrieval: An user, operator, or application acquires one or > > [O] An user > [P] A user > [R] Grammar > > more specific security automation data entries. The location > of the data may be known a priori, or may be determined based > on decisions made using information from a previous query. > > 2.1.4. Posture Attribute Evaluation > > ... > While the primary focus of this use cases is around enabling the > > [O] this use cases > [P] this use case > [R] grammar > > comparison of expected vs. actual state, the same building blocks can > support other analysis techniques that are applied to collected > posture attribute data (e.g., trending, historic analysis). > > ... > 2.2.1. Definition and Publication of Automatable Configuration > Checklists > > ... > > Each guide they produce applies to a specific model of device and > version of the operating system and provides a number of specialized > configurations depending on the devices intended function and what [O] > on the devices intended function [P] on the device's intended function [R] > grammar (possessive, not plural) > > add-on hardware modules and software licenses are installed on the > device. To enable their customers to evaluate the security posture > of their devices to ensure that all appropriate minimal security > settings are enabled, they publish an automatable configuration > checklists using a popular data format that defines what settings to > collect using a network management protocol and appropriate values > for each setting. They publish these checklist to a public security > > [O] these checklist to > [P] these checklists to > [R] grammar > > automation data store that customers can query to retrieve applicable > checklist for their deployed specialized endpoint devices. > > [O] checklist for their deployed > [P] checklist(s) for their deployed > [R] grammar > > > Automatable configuration checklist could also come from sources > other than a device vendor, such as industry groups or regulatory > authorities, or enterprises could develop their own checklists. > > This usage scenario employs the following building blocks defined in > Section 2.1.1 above: > > Data Definition: To allow guidance to be defined using standardized > or proprietary data models that will drive Collection and > Evaluation. > > [O] Collection and Evaluation. > [P] collection and evaluation. > [R] no reason to capitalize... > > Data Publication: Providing a mechanism to publish created guidance > to a security automation data store. > > Data Query: To locate and select existing guidance that may be > reused. > > ... > 2.2.2. Automated Checklist Verification > > ... > The results of checklist evaluation are provided to appropriate > operators and applications to drive additional business logic. > Specific applications for checklist evaluation results are out-of- > scope for current SACM efforts. Irrespective of specific > applications, the availability, timeliness, and liveness of results > is often of general concern. Network latency and available bandwidth > often create operational constriants that require trade-offs between > > [O] constriants > [P] contraints > [R] spelling > > these concerns and need to be considered. > > ... > > Posture Attribute Evaluation: The resulting posture attribute values > from previous Collection processes are evaluated using the > > [O] Collection > [P] collection > [R] not sure why it's capitalized; maybe a typo? > > evaluation guidance to provide a set of posture results. > > 2.2.3. Detection of Posture Deviations > > ... > When a change occurs > to posture defined in the baseline, updated posture information is > exchanged allowing operators to be notified and/or automated action > > [O] is exchanged allowing operators > [P] is exchanged, allowing operators > [R] grammar > > to be taken. > > ... > > 2.2.5. Asynchronous Compliance/Vulnerability Assessment at Ice Station > Zebra > > A university team receives a grant to do research at a government > facility in the arctic. The only network communications will be via > an intermittent low-speed high-latency high-cost satellite link. > > [O] intermittent low-speed high-latency high-cost [P] intermittent, low > speed, high latency, high cost [R] grammar/readability > > During their extended expedition they will need to show continue > > [O] During their extended expedition they will [P] During their extended > expedition, they will [R] grammar > > compliance with the security policies of the university, the > government, and the provider of the satellite network as well as keep > current on vulnerability testing. Interactive assessments are > therefore not reliable, and since the researchers have very limited > funding they need to minimize how much money they spend on network > data. > > .... > In the case of new critical vulnerabilities this collection request > > [O] In the case of new critical vulnerabilities this collection request > [P] In the case of new critical vulnerabilities, this collection request > [R] grammar > > consists only of the artifacts necessary for those vulnerabilities > and collection is only initiated for those assets that could > potentially have a new vulnerability. > > [Optional] Asset artifacts are cached in a local CMDB. When new > vulnerabilities are reported to the security automation data store, a > request to the live asset is only done if the artifacts in the CMDB > are incomplete and/or not current enough. > > ... > > The collected artifacts eventually make it back to the university > where the level of compliance and vulnerability expose is calculated > > [O] level of compliance and vulnerability expose [P] level of compliance > and vulnerability exposed [R] grammar > > and asset characteristics are compared to what is in the asset > management system for accuracy and completeness. > > ... > > > 4. Security Considerations > > This memo documents, for Informational purposes, use cases for > > [O] for Informational purposes > [P] for informational purposes > [R] not sure "informational" is capitalized. > > security automation. Specific security considerations will be > provided in related documents (e.g., requirements, architecture, > information model, data model, protocol) as appropriate to the > function described in each related document. > > > ------------- > W > > > > > -- > 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 > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- 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 --001a11c3aa745105f60511fe3197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, March 23, 2015, Waltermire, David A. <david.waltermire@nist.gov> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Warren,

I have accepted and addressed all your nits and will be posting an updated = draft with these changes soon.

You also pointed out that it would be valuable to mention in the security c= onsiderations "that a malicious party could use this collected data to= help him figure out which end points are not as well protected, and so mak= e his reconnaissance easier."

We have been working on the following text to address this issue:

One consideration for security automation is that a malicious actor could u= se the security automation infrastructure and related collected data to det= ermine endpoint weaknesses to exploit.=C2=A0 =C2=A0It is important that sec= urity considerations in the related documents identify methods to both iden= tify and prevent such activity.=C2=A0 Specifically, means for protecting th= e communications as well as the systems that store the information.=C2=A0 F= or communications between the varying SACM components there should be consi= derations for protecting the confidentiality,=C2=A0 data integrity and peer= entity authentication.=C2=A0 Also, for any systems that store information = that could be used for malicious purposes, methods to identify and protect = against unauthorized usage, inappropriate usage and denial of service need = to be considered.

Does this text address your concern?

Yup.

Looks really good.
W

=C2=A0

If so, I'll post the updated draft containing this and the other reques= ted changes.

Thanks,
Dave

-----Original Message-----
From: secdir [mailto:secdir-bounces@ietf.org] On= Behalf Of Warren Kumari
Sent: Tuesday, March 17, 2015 1:18 PM
To: draft-ietf-sacm-use-cases.a= ll@tools.ietf.org; secdir@ietf.org
Subject: [secdir] Secdir review of draft-ietf-sacm-use-cases

Be ye not afraid!

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

Summary: Ready with grammar nits.

Document reviewed:draft-ietf-sacm-use-cases-08.txt

Note: This is Endpoint Security Posture Assessment - Enterprise Use Cases A= s a use case, it mainly provides justification for SACM work, and example u= se cases. This is useful, but there is not much meat for a security review.=

One thing that the document could mention (although this could easily be do= ne in some other document) is that a malicious party could use this collect= ed data to help him figure out which end points are not as well protected, = and so make his reconnoissance=C2=A0 easier.

Nits and such:
The word "Optional" in Section 2.2.5. makes the nit checker confu= sed is in square brackets ( "[]" ) -- this makes the nit checker = assume it is a reference and so it complains. This can easily be ignored, b= ut I suspect other tools might also become confused - it may be a good idea= to wrap it in some other set of quating instead.

More nits:



1.=C2=A0 Introduction

=C2=A0....

=C2=A0 =C2=A0Togther these ideas will be used to guide development of vendo= r-

[O] Togther
[P] Together
[R] spelling

....
=C2=A0 =C2=A0It is expected that use cases for enterprises and for service<= br> =C2=A0 =C2=A0providers will largely overlap, but there are additional

[O]=C2=A0 will largely overlap, but there are additional [P] will largely o= verlap. But there are additional [R] readability



2.=C2=A0 Endpoint Posture Assessment

=C2=A0 ....

=C2=A0 =C2=A0o=C2=A0 Making the attributes available for evaluation and act= ion; and

=C2=A0 =C2=A0o=C2=A0 Verifying that the endpoint's posture is in compli= ance with
=C2=A0 =C2=A0 =C2=A0 enterprise standards and policy.

=C2=A0 =C2=A0As part of these activities it is often necessary to identify = and

[O] As part of these activities it is often necessary [P] As part of these = activities, it is often necessary [R] Readability

=C2=A0....

2.1.1.=C2=A0 Define, Publish, Query and Retrieve Security Automation Data
=C2=A0 ....
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Policies that define how to targe= t and perform the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 evaluation of a set of attributes= for different kinds or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 groups of endpoints and the asset= s they are composed of.=C2=A0 In
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some cases it may be desirable to= maintain hierarchies of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 policies as well.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 References to human oriented-data= that provide technical,

[O] human oriented-data
[P] human-oriented data
[R] correction

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 organizational, and/or policy con= text.=C2=A0 This might include
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 references to: best practices doc= uments, legal guidance and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 legislation, and instructional ma= terials related to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 automation data in question.
.....

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Organizationally defined expected= posture attribute values
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 targeted to specific evaluation g= uidance and endpoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 characteristics.=C2=A0 This allow= s a common set of guidance to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parameterized for use with differ= ent groups of endpoints.

=C2=A0 =C2=A0Processing Artifacts:=C2=A0 Data that is generated by and is s= pecific to [O] that is generated by and is specific to [P] that is generate= d by, and is specific to, [R] readability

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an individual assessment process.=C2=A0 T= his data may be used as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0part of the interactions between architec= tural components to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0drive and coordinate collection and evalu= ation activities.=C2=A0 Its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lifespan will be bounded by the lifespan = of the assessment.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0may also be exchanged and stored to provi= de historic context
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0around an assessment activity so that ind= ividual assessments
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can be grouped, evaluated, and reported i= n an enterprise
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0context.

=C2=A0 ....

=C2=A0 =C2=A0Data Definition:=C2=A0 Security automation data will guide and= inform
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0collection and evaluation processes.=C2= =A0 This data may be designed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by a variety of roles - application imple= menters may build
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security automation data into their appli= cations;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0administrators may define guidance based = on organizational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0policies; operators may define guidance a= nd attribute data as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0needed for evaluation at runtime, and so = on.=C2=A0 Data producers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0may choose to reuse data from existing st= ores of security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0automation data and may create new data.= =C2=A0 Data producers may

[O]data and may create new data
[P] data and/or may create new data
[R] I think this is what is meant? Not sure if the "create new data&qu= ot;
would be from the existing stores of data.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0develop data based on available standardi= zed or proprietary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data models, such as those used for netwo= rk management and/or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0host management.

=C2=A0 ...

=C2=A0 =C2=A0Data Retrieval:=C2=A0 An user, operator, or application acquir= es one or

[O] An user
[P] A user
[R] Grammar

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more specific security automation data en= tries.=C2=A0 The location
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of the data may be known a priori, or may= be determined based
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on decisions made using information from = a previous query.

2.1.4.=C2=A0 Posture Attribute Evaluation

=C2=A0 ...
=C2=A0 =C2=A0While the primary focus of this use cases is around enabling t= he

[O] this use cases
[P] this use case
[R] grammar

=C2=A0 =C2=A0comparison of expected vs. actual state, the same building blo= cks can
=C2=A0 =C2=A0support other analysis techniques that are applied to collecte= d
=C2=A0 =C2=A0posture attribute data (e.g., trending, historic analysis).
=C2=A0...
2.2.1.=C2=A0 Definition and Publication of Automatable Configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Checklists

=C2=A0...

=C2=A0 =C2=A0Each guide they produce applies to a specific model of device = and
=C2=A0 =C2=A0version of the operating system and provides a number of speci= alized
=C2=A0 =C2=A0configurations depending on the devices intended function and = what [O] on the devices intended function [P] on the device's intended = function [R] grammar (possessive, not plural)

=C2=A0 =C2=A0add-on hardware modules and software licenses are installed on= the
=C2=A0 =C2=A0device.=C2=A0 To enable their customers to evaluate the securi= ty posture
=C2=A0 =C2=A0of their devices to ensure that all appropriate minimal securi= ty
=C2=A0 =C2=A0settings are enabled, they publish an automatable configuratio= n
=C2=A0 =C2=A0checklists using a popular data format that defines what setti= ngs to
=C2=A0 =C2=A0collect using a network management protocol and appropriate va= lues
=C2=A0 =C2=A0for each setting.=C2=A0 They publish these checklist to a publ= ic security

[O] these checklist to
[P] these checklists to
[R] grammar

=C2=A0 =C2=A0automation data store that customers can query to retrieve app= licable
=C2=A0 =C2=A0checklist for their deployed specialized endpoint devices.

[O] checklist for their deployed
[P] checklist(s) for their deployed
[R] grammar


=C2=A0 =C2=A0Automatable configuration checklist could also come from sourc= es
=C2=A0 =C2=A0other than a device vendor, such as industry groups or regulat= ory
=C2=A0 =C2=A0authorities, or enterprises could develop their own checklists= .

=C2=A0 =C2=A0This usage scenario employs the following building blocks defi= ned in
=C2=A0 =C2=A0Section 2.1.1 above:

=C2=A0 =C2=A0Data Definition:=C2=A0 To allow guidance to be defined using s= tandardized
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or proprietary data models that will driv= e Collection and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Evaluation.

[O] Collection and Evaluation.
[P] collection and evaluation.
[R] no reason to capitalize...

=C2=A0 =C2=A0Data Publication:=C2=A0 Providing a mechanism to publish creat= ed guidance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to a security automation data store.

=C2=A0 =C2=A0Data Query:=C2=A0 To locate and select existing guidance that = may be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reused.

=C2=A0 =C2=A0...
2.2.2.=C2=A0 Automated Checklist Verification

=C2=A0 =C2=A0...
=C2=A0 =C2=A0The results of checklist evaluation are provided to appropriat= e
=C2=A0 =C2=A0operators and applications to drive additional business logic.=
=C2=A0 =C2=A0Specific applications for checklist evaluation results are out= -of-
=C2=A0 =C2=A0scope for current SACM efforts.=C2=A0 Irrespective of specific=
=C2=A0 =C2=A0applications, the availability, timeliness, and liveness of re= sults
=C2=A0 =C2=A0is often of general concern.=C2=A0 Network latency and availab= le bandwidth
=C2=A0 =C2=A0often create operational constriants that require trade-offs b= etween

[O] constriants
[P] contraints
[R] spelling

=C2=A0 =C2=A0these concerns and need to be considered.

=C2=A0 =C2=A0...

=C2=A0 =C2=A0Posture Attribute Evaluation:=C2=A0 The resulting posture attr= ibute values
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from previous Collection processes are ev= aluated using the

[O] Collection
[P] collection
[R] not sure why it's capitalized; maybe a typo?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0evaluation guidance to provide a set of p= osture results.

2.2.3.=C2=A0 Detection of Posture Deviations

=C2=A0 ...
=C2=A0 When a change occurs
=C2=A0 =C2=A0to posture defined in the baseline, updated posture informatio= n is
=C2=A0 =C2=A0exchanged allowing operators to be notified and/or automated a= ction

[O] is exchanged allowing operators
[P] is exchanged, allowing operators
[R] grammar

=C2=A0 =C2=A0to be taken.

=C2=A0...

2.2.5.=C2=A0 Asynchronous Compliance/Vulnerability Assessment at Ice Statio= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Zebra

=C2=A0 =C2=A0A university team receives a grant to do research at a governm= ent
=C2=A0 =C2=A0facility in the arctic.=C2=A0 The only network communications = will be via
=C2=A0 =C2=A0an intermittent low-speed high-latency high-cost satellite lin= k.

[O] intermittent low-speed high-latency high-cost [P] intermittent, low spe= ed, high latency, high cost [R] grammar/readability

=C2=A0 =C2=A0During their extended expedition they will need to show contin= ue

[O] During their extended expedition they will [P] During their extended ex= pedition, they will [R] grammar

=C2=A0 =C2=A0compliance with the security policies of the university, the =C2=A0 =C2=A0government, and the provider of the satellite network as well = as keep
=C2=A0 =C2=A0current on vulnerability testing.=C2=A0 Interactive assessment= s are
=C2=A0 =C2=A0therefore not reliable, and since the researchers have very li= mited
=C2=A0 =C2=A0funding they need to minimize how much money they spend on net= work
=C2=A0 =C2=A0data.

....
=C2=A0 =C2=A0In the case of new critical vulnerabilities this collection re= quest

[O] In the case of new critical vulnerabilities this collection request [P]= In the case of new critical vulnerabilities, this collection request [R] g= rammar

=C2=A0 =C2=A0consists only of the artifacts necessary for those vulnerabili= ties
=C2=A0 =C2=A0and collection is only initiated for those assets that could =C2=A0 =C2=A0potentially have a new vulnerability.

=C2=A0 =C2=A0[Optional] Asset artifacts are cached in a local CMDB.=C2=A0 W= hen new
=C2=A0 =C2=A0vulnerabilities are reported to the security automation data s= tore, a
=C2=A0 =C2=A0request to the live asset is only done if the artifacts in the= CMDB
=C2=A0 =C2=A0are incomplete and/or not current enough.

...

=C2=A0 =C2=A0The collected artifacts eventually make it back to the univers= ity
=C2=A0 =C2=A0where the level of compliance and vulnerability expose is calc= ulated

[O] level of compliance and vulnerability expose [P] level of compliance an= d vulnerability exposed [R] grammar

=C2=A0 =C2=A0and asset characteristics are compared to what is in the asset=
=C2=A0 =C2=A0management system for accuracy and completeness.

...


4.=C2=A0 Security Considerations

=C2=A0 =C2=A0This memo documents, for Informational purposes, use cases for=

[O] for Informational purposes
[P] for informational purposes
[R] not sure "informational" is capitalized.

=C2=A0 =C2=A0security automation.=C2=A0 Specific security considerations wi= ll be
=C2=A0 =C2=A0provided in related documents (e.g., requirements, architectur= e,
=C2=A0 =C2=A0information model, data model, protocol) as appropriate to the=
=C2=A0 =C2=A0function described in each related document.


-------------
W




--
I don't think the execution is relevant when it was obviously a bad ide= a in the first place.
This is like putting rabid weasels in your pants, and later expressing regr= et at having chosen those particular rabid weasels and that pair of pants.<= br> =C2=A0 =C2=A0---maf

_______________________________________________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


--
I don't think the execution is relevant whe= n it was obviously a bad idea in the first place.
This is like putting r= abid weasels in your pants, and later expressing regret at having chosen th= ose particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf=
--001a11c3aa745105f60511fe3197-- From nobody Tue Mar 24 08:36: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 315F11A8953 for ; Tue, 24 Mar 2015 08:36:54 -0700 (PDT) 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, HTML_MESSAGE=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 RdgT8KATqeKV for ; Tue, 24 Mar 2015 08:36:53 -0700 (PDT) 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 F2C751A8932 for ; Tue, 24 Mar 2015 08:36:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUB90899; Tue, 24 Mar 2015 15:36:51 +0000 (GMT) Received: from SZXEML426-HUB.china.huawei.com (10.82.67.181) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Mar 2015 15:36:40 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.131]) by szxeml426-hub.china.huawei.com ([10.82.67.181]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 23:36:29 +0800 From: Tina TSOU To: "Org Secdir@Ietf." Thread-Topic: Is secdir lunch at Room Pavilion 12pm today? Thread-Index: AdBmSEwHvFAEeAv1QKKPzUsu9oGoXQ== Date: Tue, 24 Mar 2015 15:36:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D0B986A366384E0E9AFA841D44A0C414huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [secdir] Is secdir lunch at Room Pavilion 12pm today? 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, 24 Mar 2015 15:36:54 -0000 --_000_D0B986A366384E0E9AFA841D44A0C414huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCklzIHNlY2RpciBsdW5jaCBhdCBSb29tIFBhdmlsaW9uIDEycG0gdG9kYXk/ DQoNCg0KVGhhbmsgeW91LA0KVGluYQ0K --_000_D0B986A366384E0E9AFA841D44A0C414huaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <477FE5D144D5DA43807E84E2EB61D216@huawei.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzcHQ7Ij5EZWFyIGFsbCw8L3NwYW4+PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JcyBzZWNkaXIgbHVuY2ggYXQgUm9vbSBQYXZpbGlv biAxMnBtIHRvZGF5PzwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGFuayB5b3UsPC9kaXY+DQo8ZGl2PlRpbmE8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_D0B986A366384E0E9AFA841D44A0C414huaweicom_-- From nobody Tue Mar 24 08:39: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 122E01A89AA for ; Tue, 24 Mar 2015 08:39:01 -0700 (PDT) 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, 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 sIPL6yoTGuLW for ; Tue, 24 Mar 2015 08:38:57 -0700 (PDT) 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 B0B2D1A898E for ; Tue, 24 Mar 2015 08:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EBDBBE9C; Tue, 24 Mar 2015 15:38:31 +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 7zdfXX98mIuY; Tue, 24 Mar 2015 15:38:30 +0000 (GMT) Received: from [31.133.180.113] (dhcp-b471.meeting.ietf.org [31.133.180.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A6FD8BE9A; Tue, 24 Mar 2015 15:38:29 +0000 (GMT) Message-ID: <551184F3.4030906@cs.tcd.ie> Date: Tue, 24 Mar 2015 15:38:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tina TSOU , "Org Secdir@Ietf." References: In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Is secdir lunch at Room Pavilion 12pm today? 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, 24 Mar 2015 15:39:01 -0000 Yes. S. On 24/03/15 15:36, Tina TSOU wrote: > Dear all, > > Is secdir lunch at Room Pavilion 12pm today? > > > Thank you, > Tina > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Tue Mar 24 10:37: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 9693D1AC414 for ; Tue, 24 Mar 2015 10:37:05 -0700 (PDT) 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 BTJzEBpmN0CZ for ; Tue, 24 Mar 2015 10:37:04 -0700 (PDT) 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 0089F1A900B for ; Tue, 24 Mar 2015 10:37:03 -0700 (PDT) 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 t2OHb0kh015321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 24 Mar 2015 19:37:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2OHb0rQ004042; Tue, 24 Mar 2015 19:37:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21777.41148.565594.540035@fireball.kivinen.iki.fi> Date: Tue, 24 Mar 2015 19:37:00 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [secdir] Requirements for review tracker tool draft. 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, 24 Mar 2015 17:37:05 -0000 http://datatracker.ietf.org/doc/draft-sparks-genarea-review-tracker/ Currently this has been reviewed by the review team secretaries, but if you as reviewer have any more requiremetns it would be good idea to get them in here now.... -- kivinen@iki.fi From nobody Tue Mar 24 11:18:53 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 2F6191A6EFB for ; Tue, 24 Mar 2015 11:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSpQN585CHLE for ; Tue, 24 Mar 2015 11:18:43 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1821A8901 for ; Tue, 24 Mar 2015 11:18:43 -0700 (PDT) Received: by lbbsy1 with SMTP id sy1so824418lbb.1 for ; Tue, 24 Mar 2015 11:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ioPTrFK7ujA+GDKyIWy0Jhz1w/hdBNCBjVb18Lz5MvM=; b=sLB4+URF0DRyoKjx8JYM4/EEU+0SO5srEQD9NJDUAhR5vdmiRhC1by8ozrQAZcH1gs xz+LDEVbYEGBHEfUoDPxs8llOXgCC4TUMVDg7wgwov1sqybYwVktgffiD/7FSgtH22Si PTetRFu8PYFql/x8j/Bz8QlM5yangwzcA3UlRlG/crnX/uaeholwPxf76QVr+hC3JdBH vFwN2AL+pKN8FA4qTFxV/iTVtkRWaBdOBdrarg+mk4ZPS6hU1h3DjOCWms8FjWwZTNr3 J6NQ3K72g2iYXU6Q5+C6O33ZmVH7Pyhym7yZZd2SNxzQ8PxkbXKTG/Qc8LCn4GERBaow o7Ag== MIME-Version: 1.0 X-Received: by 10.112.155.196 with SMTP id vy4mr5059664lbb.56.1427221121697; Tue, 24 Mar 2015 11:18:41 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 24 Mar 2015 11:18:41 -0700 (PDT) Date: Tue, 24 Mar 2015 14:18:41 -0400 Message-ID: From: Kathleen Moriarty To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=089e0112cac2f98d0005120ccfcf Archived-At: Subject: [secdir] processing errata 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, 24 Mar 2015 18:18:49 -0000 --089e0112cac2f98d0005120ccfcf Content-Type: text/plain; charset=UTF-8 Hello, As discussed in the SecDir lunch, we need help from the chairs and experts to address the outstanding list of errata. This means that we need the chairs, experts, and in some cases WG to review submitted errata to determine if the report correctly identifies an issue with the RFC or not. Ideally, you would respond to the original email sent on the errata that includes the RFC tools address, authors, chairs and ADs. If you don't have that original message, your recommendation on the errata could be sent to Stephen and I for processing. If the errata report is not correct, we'll need an explanation to include with the rejection. This can be text or can be a pointer to a mailing list discussion of the errata. If the errata is listed as technical and you think it is editorial, please let us know that as well as ADs can make that change as the errata is "processed". In some cases, they will be quick to verify or reject and in others, conferring with the RFC editors and WG will be necessary. Here is the link to the errata page that lets you search by area: http://www.rfc-editor.org/errata.php Here is background on actions taken with errata: https://www.ietf.org/iesg/statement/errata-processing.html If you are not a chair and want to help, that is welcome. There are a bunch that don't fall into WGs or the WG is now closed. This may require outreach to the editors. Thank you! -- Best regards, Kathleen --089e0112cac2f98d0005120ccfcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

As discussed in the SecDir lunch, we need help from the chairs and expert= s to address the outstanding list of errata.=C2=A0 This means that we need = the chairs, experts, and in some cases WG to review submitted errata to det= ermine if the report correctly identifies an issue with the RFC or not.=C2= =A0 Ideally, you would respond to the original email sent on the errata tha= t includes the RFC tools address, authors, chairs and ADs.=C2=A0 If you don= 't have that original message, your recommendation on the errata could = be sent to Stephen and I for processing.

If the er= rata report is not correct, we'll need an explanation to include with t= he rejection.=C2=A0 This can be text or can be a pointer to a mailing list = discussion of the errata.

If the errata is listed = as technical and you think it is editorial, please let us know that as well= as ADs can make that change as the errata is "processed".
<= div>
In some cases, they will be quick to verify or reject an= d in others, conferring with the RFC editors and WG will be necessary.=C2= =A0

H= ere is the link to the errata page that lets you search by area:

Here is background on actions taken with errata:

<= div>
If you are not a chair and want to help, that is welcome= .=C2=A0 There are a bunch that don't fall into WGs or the WG is now clo= sed.=C2=A0 This may require outreach to the editors. =C2=A0

<= /div>
Thank you!
--

Best regards,
Kathleen
--089e0112cac2f98d0005120ccfcf-- From nobody Thu Mar 26 11: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 2B1F71A8A42 for ; Thu, 26 Mar 2015 11:07:16 -0700 (PDT) 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 aAKommTGJa_h for ; Thu, 26 Mar 2015 11:07:14 -0700 (PDT) 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 3CCEB1A894A for ; Thu, 26 Mar 2015 11:07:13 -0700 (PDT) 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 t2QI7AUt013468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 26 Mar 2015 20:07:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2QI7AM7007556; Thu, 26 Mar 2015 20:07:10 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21780.19150.230146.627165@fireball.kivinen.iki.fi> Date: Thu, 26 Mar 2015 20:07:10 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 min X-Total-Time: 6 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, 26 Mar 2015 18:07:16 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Hilarie Orman is next in the rotation. For telechat 2015-04-09 Reviewer LC end Draft Tobias Gondrom T 2015-03-12 draft-ietf-appsawg-uri-scheme-reg-04 Warren Kumari T 2015-04-07 draft-ietf-netext-pmip-qos-wifi-07 Ben Laurie T 2015-03-23 draft-ietf-oauth-dyn-reg-management-12 Matt Lepinski T 2015-04-02 draft-klensin-smtp-521code-05 Chris Lonvick T 2015-04-06 draft-ietf-appsawg-multipart-form-data-08 Catherine Meadows TR2015-03-23 draft-ietf-roll-applicability-home-building-09 Catherine Meadows T 2015-04-02 draft-ietf-httpbis-auth-info-04 Sam Weiler T 2015-02-16 draft-ietf-6man-resilient-rs-05 Brian Weis TR2015-03-20 draft-ietf-radext-dynamic-discovery-13 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Alexey Melnikov 2015-04-08 draft-ietf-idr-flowspec-redirect-rt-bis-03 Matthew Miller 2015-04-08 draft-ietf-idr-ls-distribution-10 Adam Montville 2015-04-08 draft-ietf-isis-extended-sequence-no-tlv-04 Sandy Murphy 2015-03-30 draft-ietf-tls-sslv3-diediedie-02 Yoav Nir 2015-04-02 draft-ietf-httpauth-digest-15 Magnus Nystrom 2015-04-07 draft-ietf-scim-use-cases-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Tue Mar 31 21:54: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 100A01A883D; Tue, 31 Mar 2015 21:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtsxCYjsvrWm; Tue, 31 Mar 2015 21:54:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1A31A8838; Tue, 31 Mar 2015 21:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=551; q=dns/txt; s=iport; t=1427864042; x=1429073642; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uru6G7oRJqqKoaPBNlunvwc70nyhmhHtkc5kkGhsX6M=; b=e97wpI/qUmq6TNgqLTLVCU+/tMQEQd2dlpKnuzOjx3wLq8xG8WDPSwzG G5GL8JBcJW6qhLpAUbziLURQvu5+EEcsNy7OrrDQiIOPd9jrPBfoDO2QF GBJdmawuksUiw9yUygP6/2c4RmNgwvRylnFpQW2Cxr7DPlonIav03aiL7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQDFeBtV/5FdJa1cgwaBM8t4gUZMAQEBAQEBfYQbeRIBgQAnBAENiDTODAEBAQEBAQEBAQEBAQEBAQEBAQEZkCGDHoEWAQSQYol1lDsig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="408264193" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP; 01 Apr 2015 04:54:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t314s0GY021157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 04:54:00 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.86]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 23:54:00 -0500 From: "Brian Weis (bew)" To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-radext-dynamic-discovery-13 Thread-Index: AQHQbDfeNoJmN5Gq3EulDPmlP6Vogw== Date: Wed, 1 Apr 2015 04:54:00 +0000 Message-ID: <779642F1-4094-4524-A6B8-EE4E40B1CF8A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.211] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-radext-dynamic-discovery.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-13 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, 01 Apr 2015 04:54:03 -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 com= ments were written primarily for the benefit of the security area directors= .=20 Previously I reviewed draft-ietf-radext-dynamic-discovery-12, and while I d= idn=92t have any particular issues with it there were some questions and su= ggestions for clarifying trust model. The current draft added some really v= aluable text and figures. I believe it is ready to be published. Brian