From nobody Fri Mar 14 14:23:48 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7821A01E0 for ; Fri, 14 Mar 2014 14:23:47 -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, 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 g4j6Xha4HnmA for ; Fri, 14 Mar 2014 14:23:44 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 989A41A01EB for ; Fri, 14 Mar 2014 14:23:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 024A624034B for ; Fri, 14 Mar 2014 14:23:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-57.clppva.east.verizon.net [70.106.134.57]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8CD4A240063 for ; Fri, 14 Mar 2014 14:23:37 -0700 (PDT) Message-ID: <5323735A.4080908@joelhalpern.com> Date: Fri, 14 Mar 2014 17:23:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "karp@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------030306070305080506010605" Archived-At: http://mailarchive.ietf.org/arch/msg/karp/xiVtoKkEL2FhGYsAS1JkZGJYGYc Subject: [karp] Fwd: Routing Area meeting draft minutes X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 21:23:47 -0000 This is a multi-part message in MIME format. --------------030306070305080506010605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Minutes from the KARP session on AKM can be found at the bottom of these (thanks Deborah). Please read them, as Brian and I hope to start followup on the list soon. Yours, Joel -------- Original Message -------- Subject: Routing Area meeting draft minutes Date: Fri, 14 Mar 2014 20:57:24 +0000 From: BRUNGARD, DEBORAH A To: routing-discussion@ietf.org Hi, Draft minutes are uploaded at: _http://www.ietf.org/proceedings/89/minutes/minutes-89-rtgarea_ Thanks to all who provided Working Group summaries. Comments welcome. Deborah --------------030306070305080506010605 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --------------030306070305080506010605-- From nobody Sat Mar 15 05:48:41 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DC11A0130; Sat, 15 Mar 2014 05:48:35 -0700 (PDT) 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_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wf10jJF_6y2Y; Sat, 15 Mar 2014 05:48:32 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) by ietfa.amsl.com (Postfix) with ESMTP id E1E4D1A012E; Sat, 15 Mar 2014 05:48:31 -0700 (PDT) Received: from DB3PRD0210HT001.eurprd02.prod.outlook.com (157.56.253.69) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.898.11; Sat, 15 Mar 2014 12:48:23 +0000 Message-ID: <011701cf404c$167fcc40$4001a8c0@gateway.2wire.net> From: t.petch To: References: <4A1562797D64E44993C5CBF38CF1BE48126ADE36@ESESSMB301.ericsson.se> <09d601cf3a34$373a1ee0$4001a8c0@gateway.2wire.net> Date: Sat, 15 Mar 2014 12:36:32 +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: [157.56.253.69] X-ClientProxiedBy: DBXPR07CA020.eurprd07.prod.outlook.com (10.141.8.178) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 015114592F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51444003)(92566001)(85852003)(97186001)(97336001)(93136001)(92726001)(74366001)(54316002)(74706001)(56776001)(47976001)(47736001)(50986001)(44736004)(49866001)(46102001)(61296002)(56816005)(95666003)(88136002)(90146001)(89996001)(83072002)(47446002)(4396001)(50226001)(31966008)(74662001)(74502001)(84392001)(53806001)(50466002)(74876001)(33646001)(85306002)(76482001)(83322001)(80976001)(19580395003)(81342001)(81542001)(69226001)(87976001)(87266001)(87286001)(42186004)(76796001)(77096001)(76786001)(77156001)(59766001)(77982001)(14496001)(93516002)(23756003)(51856001)(62966002)(95416001)(94946001)(94316002)(93916002)(86362001)(66066001)(80022001)(65816001)(44716002)(79102001)(62236002)(63696002)(47776003)(20776003)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:DB3PRD0210HT001.eurprd02.prod.outlook.com; FPR:1E66F255.8F7497F6.4BEF1387.D5E92621.201F1; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/karp/xJNKeS60Ux7B9XTWocie6OUz7Cc Cc: karp@ietf.org Subject: [karp] draft-mahesh-karp-lmp-analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 12:48:35 -0000 At IETF89, I recall CCAMP was asked if it would review the KARP analysis of LMP and four assented, of which I was one. I would like any discussion to take place on an ietf.org list for its archiving and reliable distribution. I would be interested to hear the views of the other three. My first two thoughts are - Section 1 seems misdirected. KARP categorises routing protocols and one such is TCP point-to-point which encompasses BGP, LDP, PCEP and MSDP but notes in RFC6518, RFC6862 that LDP has an unsecured UDP part which then seems to be neglected. LMP does not seem to fit any category being point-to-point over UDP with mandatory security and indeed seems to be ignored by KARP. So I think that this section needs reworking. - Section 2.5 is a paraphrase of parts of s.7 of RFC4204 which seems to me less clear and less precise - I think that the original text should be used. Tom Petch From nobody Sat Mar 15 09:45:10 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882C1A00C3 for ; Sat, 15 Mar 2014 09:45:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hA7mY5CYBRBm for ; Sat, 15 Mar 2014 09:45:05 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) by ietfa.amsl.com (Postfix) with ESMTP id 08F6E1A00F9 for ; Sat, 15 Mar 2014 09:45:04 -0700 (PDT) Received: from DBXPRD0210HT004.eurprd02.prod.outlook.com (157.56.253.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.898.11; Sat, 15 Mar 2014 16:44:56 +0000 Message-ID: <004a01cf406d$21929060$4001a8c0@gateway.2wire.net> From: t.petch To: "Joel M. Halpern" , References: <5323735A.4080908@joelhalpern.com> Date: Sat, 15 Mar 2014 16:37:23 +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: [157.56.253.181] X-ClientProxiedBy: AMXPR07CA003.eurprd07.prod.outlook.com (10.242.64.43) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 015114592F X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(2473001)(13464003?= =?iso-8859-1?Q?)(51704005)(189002)(54164003)(199002)(377454003)(84392001)?= =?iso-8859-1?Q?(74706001)(74876001)(97336001)(97186001)(74366001)(8154200?= =?iso-8859-1?Q?1)(50466002)(81342001)(95666003)(19580395003)(19580405001)?= =?iso-8859-1?Q?(15202345003)(83322001)(62966002)(61296002)(80976001)(8999?= =?iso-8859-1?Q?6001)(14496001)(90146001)(56816005)(94946001)(74662001)(31?= =?iso-8859-1?Q?966008)(47446002)(74502001)(85852003)(83072002)(87976001)(?= =?iso-8859-1?Q?79102001)(62236002)(44716002)(47776003)(20776003)(63696002?= =?iso-8859-1?Q?)(88136002)(59766001)(77982001)(4396001)(33646001)(9431600?= =?iso-8859-1?Q?2)(47976001)(50986001)(50226001)(49866001)(47736001)(86362?= =?iso-8859-1?Q?001)(93916002)(93516002)(93136001)(92726001)(92566001)(237?= =?iso-8859-1?Q?56003)(44736004)(95416001)(87286001)(76482001)(85306002)(5?= =?iso-8859-1?Q?3806001)(77156001)(77096001)(54316002)(69226001)(42186004)?= =?iso-8859-1?Q?(76796001)(56776001)(76786001)(65816001)(80022001)(4610200?= =?iso-8859-1?Q?1)(66066001)(15975445006)(87266001)(51856001)(74416001)(77?= =?iso-8859-1?Q?26001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR07MB060;H:DBXPRD02?= =?iso-8859-1?Q?10HT004.eurprd02.prod.outlook.com;FPR:78DF6170.38E3AFCE.41?= =?iso-8859-1?Q?D05D0F.D8AEDFE8.201B1;MLV:nov;PTR:InfoNoRecords;MX:1;A:0;L?= =?iso-8859-1?Q?ANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/karp/wNVOsBoOL56w5q1EL9Xd3ewSlts Subject: Re: [karp] Fwd: Routing Area meeting draft minutes X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 16:45:09 -0000 >From my MUA, the blob at the bottom was not recognised as a URI. >From the KARP List archive, the URI is recognised but generates 404. http://www.ietf.org/proceedings/89/minutes/minutes-89-rtgarea works for me Tom Petch ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Friday, March 14, 2014 9:23 PM Subject: [karp] Fwd: Routing Area meeting draft minutes > Minutes from the KARP session on AKM can be found at the bottom of these > (thanks Deborah). Please read them, as Brian and I hope to start > followup on the list soon. > > Yours, > Joel > > > -------- Original Message -------- > Subject: Routing Area meeting draft minutes > Date: Fri, 14 Mar 2014 20:57:24 +0000 > From: BRUNGARD, DEBORAH A > To: routing-discussion@ietf.org > > > > Hi, > Draft minutes are uploaded at: > _http://www.ietf.org/proceedings/89/minutes/minutes-89-rtgarea_ > Thanks to all who provided Working Group summaries. > Comments welcome. > Deborah > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From nobody Sat Mar 15 11:31:11 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5672B1A0189; Sat, 15 Mar 2014 11:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.183 X-Spam-Level: X-Spam-Status: No, score=-99.183 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 KuxOE5io5lwu; Sat, 15 Mar 2014 11:31:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 844091A0182; Sat, 15 Mar 2014 11:31:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2FIUvVK011583; Sat, 15 Mar 2014 18:30:57 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2FIUtOx011569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Mar 2014 18:30:56 GMT From: "Adrian Farrel" To: References: <4A1562797D64E44993C5CBF38CF1BE48126ADE36@ESESSMB301.ericsson.se> <09d601cf3a34$373a1ee0$4001a8c0@gateway.2wire.net> <011701cf404c$167fcc40$4001a8c0@gateway.2wire.net> In-Reply-To: <011701cf404c$167fcc40$4001a8c0@gateway.2wire.net> Date: Sat, 15 Mar 2014 18:30:56 -0000 Message-ID: <258701cf407c$b559d740$200d85c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGwjD6eVacvjeN4CEMdnhbkfI2KbgH/778lAeKEf4WbAMzfUA== Content-language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20568.001 X-TM-AS-Result: No--41.561-8.0-31-10 X-imss-scan-details: No--41.561-8.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBdpLkh5p97g/SG/+sPtZVkguwtqyXlE6FrMbakJN8OeYSw 1aQcbbbPcSe7L093ISP1L9lya5h8WoqDc0U+Or7vcFSPyuy3EQRAJ/ashI7fOxER5MrEGoh56lQ 6W7VWfxBmEK8SRKooe95CEY/sdra3lIoD7ilwbcwM+FbAnNWFvlAI6wCVrE3vHEF4M2lVxHJR14 zaVEvx/F3yuV9b9q3ctQ6thLcKSiKqDnzRgK0zc7wfXVYjoVWN+q1Y+/eEArZnnK6mXN72m7T4d wpiDVfTTbjXaX66zFa3MzqG06DgJgepViKE2mYPwMyV95EWVHzNUTeBBPKQKv0TP/kikeqnKqJE 7YcmGJLE14wdDSrEO/8yFK3j74qYxEEtnnH5KRc1yhbbA7We0/JVuNtKMtYMzsQ8iRVyD47GEfo tTZgUJZq3ZKM6g+itwALrqsQleDEJdnwVDCoumP2s/NQrSCg+EVPWge4LhQ8kN+07hooJG9u0gm U2trdKeqrFytEqJ14dc1qflZKquPJNA/Pk8eZ22OSj4qJA9QZxb5XAeatg5cLFbEAzpZqnzhDLX qypizGZE8hH1Pgti2phGQuiEFaXr+4qRK0heTnis+pmCrL3d2GNLTRnb5YtGNAPebYwJ/vHnkbR IMclW/r9HYBfHWjmTugiO6yIdorXFDY6Be2LlctfHufnayoGGbJMFqqIm9xrH7R0RhorDEm/5Xx BY2qo9J4o9HEPnvaW7pKmFvxafczLorbh+KyrnJ5tL+LbGOMFwIQBmQewZwFbHA9TqNLQK937aF dF5XOkQnlGNVrR3ZYlxuk1ogQA+zoAW8R15l+eAiCmPx4NwGNn8XPiALIb+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: http://mailarchive.ietf.org/arch/msg/karp/S6Kt6HUQsR0s4JVcYN_8JmavNbg Cc: karp@ietf.org Subject: Re: [karp] [CCAMP] draft-mahesh-karp-lmp-analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 18:31:09 -0000 Hi, Tom's review of this document has tipped my guilt index. Here is my brief review. 1. Although LMP is not strictly speaking a routing protocol, I have no objections to an analysis of the security considerations. I do, however, wonder whether RFC 6518 provides the best basis for such an analysis considering how that RFC is tuned towards routing protocols which are a different animal from LMP. I note that LMP is not listed in RFC 6518 although it is in the KARP charter. 2. I don't really think this document does what it sets out to do. Or if it does, it does so in a very round-about way. RFC 6518 Section 4.2 provides a series of steps. I might have expected corresponding sections in this draft. A step-by-step approach would have made cross-checking against RFC 6518 very much easier. 3. I think there is a lot of text in this document that could be pruned. No need to repeat background material on security aims of the IAB. No need to quote extensively from other RFCs when a reference will=20 do. It would be nice to cut this document down to the bare bones so that readers can see the bottom line. 4. Section 2.3 says: "LMP [RFC4204] recommends the use of IPSec for authentication" I think that RFC 4204 is stronger than a recommendation. 5. Section 2.3 says: "That document [RFC 4204] also states that there is currently no requirement that LMP headers or payload be encrypted." I think that Section 15.1 of RFC 4204 is stronger than "currently". 6. Section 2.4 says The 32-bit Message_Id number space is not large enough to guarantee that the Message_Id number will not wrap around within a reasonable long period. Therefore, the system is susceptible to a replay attack. This is a very important statement. (I don't think it falls within the remit of RFC 6518, but it still deserves to be made and=20 considered.) However, there is no analysis of why it is believed that 32 bits are not enough for a "reasonable long period". How often does the=20 author believe that a new Message_Id will be used in normal LMP=20 processing? What is a "reasonable long period"? What are the replay characteristics that would result? 7. Section 2.4 says In addition, LMP does not provide for a generation of a unique monotonically increasing sequence numbers across a failure or a restart. This is partially true. The LMP protocol spec does not require this. On the other hand, the protocol spec does require that a restart be detectable at the remote end. So why does the author believe monotonic increasing is needed over a restart? Compare a restart with a new CC. 8. Section 4 of this document claims to compare against sections 4.1=20 and 4.2 of RFC 6518. The Abstract only promised to use section 4.2. However, I find it hard to see the comparison with 6518 in the text. 9. The "solutions" in Section 4.1 have me more than a little confused. - "Maintaining Message_Id numbers in stable memory" presumably means non-volatile or persistent storage. This can hardly be a protocol requirement, so let's dig... I think that this is intended to be implementation advice in order to meet the requirement that Message_Id is monotonic increasing=20 even through restart. But I don't see that requirement in RFC 4204 and I don't see it derived in this document. So, while an=20 implementation could do this (and note that 4204 discusses what=20 happens when an LMP implementation can and cannot retain=20 information about a TE link over a restart) I don't see why an=20 implementation would be required to do this. Maybe it is a suggestion that it is OK to give an implementer, but it seems heavy. - Two methods are suggested to seed the Message_Id field after restart. I have two issues with this: - Firstly it goes against the previous suggestion that Message_Id needs to be retained in non-volatile memory over a restart. If you are going to use a clock-based seed then why bother storing=20 the information? - Secondly it assumes that an implementation needs this advice. Well, perhaps it does! But 4204 says nothing about how Message_Id is seeded and it would be a na=EFf implementer who keeps = returning to one when a control channel restarts (or who started at one in=20 the first place). - The final paragraph of 4.1 seems to be trying to say a lot in one paragraph. I see: - There is already a "handshake" defined (presumably you mean=20 Section 8 of RFC 4204) and so the "rollback of Message_Id numbers across a system restart or failure" is not actually an issue that needs attention. - There is a problem with one of the two clock-based mechanisms=20 you suggested in the previous bullet list. Perhaps it would be better to not make the suggestion? 10. Having made a big thing earlier in the document about Message_Id=20 wrapping and the risk from replay attacks, Section 4.1 doesn't=20 suggest any solution (not that I think one is needed). 11. Disappointingly, there is no discussion of key management in the gap analysis section. Does that mean that LMP scores top marks on the KARP scale and needs no further work? All in all, I think the totality of the document boils down to Section=20 4.1, and I don't see it identifying any specific issues for LMP that=20 need the attention of a protocol team. Of course, this might change if the document gives attention to key management, but I don't think so. Thus, while it is reassuring to have a note of record saying "LMP security seems OK", I don't think we need to make a big thing of it. Thanks, Adrian > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of t.petch > Sent: 15 March 2014 12:37 > To: ccamp@ietf.org > Cc: karp@ietf.org > Subject: [CCAMP] draft-mahesh-karp-lmp-analysis >=20 > At IETF89, I recall CCAMP was asked if it would review the KARP = analysis > of LMP and four assented, of which I was one. I would like any > discussion to take place on an ietf.org list for its archiving and > reliable distribution. I would be interested to hear the views of the > other three. >=20 > My first two thoughts are >=20 > - Section 1 seems misdirected. KARP categorises routing protocols and > one such is TCP point-to-point which encompasses BGP, LDP, PCEP and = MSDP > but notes in RFC6518, RFC6862 that LDP has an unsecured UDP part which > then seems to be neglected. LMP does not seem to fit any category = being > point-to-point over UDP with mandatory security and indeed seems to be > ignored by KARP. So I think that this section needs reworking. > - Section 2.5 is a paraphrase of parts of s.7 of RFC4204 which seems = to > me less clear and less precise - I think that the original text should > be used. >=20 > Tom Petch >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From nobody Mon Mar 17 03:40:03 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58681A03CC; Mon, 17 Mar 2014 03:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 d0oxby0pCGWh; Mon, 17 Mar 2014 03:39:58 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id 16D581A03C7; Mon, 17 Mar 2014 03:39:56 -0700 (PDT) Received: from DBXPRD0210HT002.eurprd02.prod.outlook.com (157.56.253.181) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 17 Mar 2014 10:39:47 +0000 Message-ID: <028b01cf41cc$721bebc0$4001a8c0@gateway.2wire.net> From: t.petch To: Adrian Farrel , References: <4A1562797D64E44993C5CBF38CF1BE48126ADE36@ESESSMB301.ericsson.se> <09d601cf3a34$373a1ee0$4001a8c0@gateway.2wire.net> <011701cf404c$167fcc40$4001a8c0@gateway.2wire.net> <258701cf407c$b559d740$200d85c0$@olddog.co.uk> Date: Mon, 17 Mar 2014 10:34:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: [157.56.253.181] X-ClientProxiedBy: AM3PR07CA006.eurprd07.prod.outlook.com (10.242.16.46) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Forefront-PRVS: 0153A8321A X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(514440?= =?iso-8859-1?Q?03)(164054003)(13464003)(199002)(189002)(95416001)(8134200?= =?iso-8859-1?Q?1)(69226001)(20776003)(81542001)(47776003)(84392001)(95666?= =?iso-8859-1?Q?003)(80022001)(66066001)(92566001)(33646001)(50466002)(748?= =?iso-8859-1?Q?76001)(92726001)(74706001)(65816001)(74366001)(4396001)(74?= =?iso-8859-1?Q?502001)(47446002)(31966008)(74662001)(94946001)(63696002)(?= =?iso-8859-1?Q?85306002)(97186001)(93136001)(44736004)(93516002)(94316002?= =?iso-8859-1?Q?)(93916002)(97336001)(47736001)(47976001)(50986001)(498660?= =?iso-8859-1?Q?01)(86362001)(50226001)(80976001)(23756003)(42186004)(5185?= =?iso-8859-1?Q?6001)(14496001)(53806001)(87976001)(79102001)(61296002)(76?= =?iso-8859-1?Q?786001)(90146001)(44716002)(77156001)(62236002)(76796001)(?= =?iso-8859-1?Q?83072002)(77096001)(62966002)(85852003)(87286001)(87266001?= =?iso-8859-1?Q?)(76482001)(56816005)(56776001)(19580405001)(88136002)(597?= =?iso-8859-1?Q?66001)(89996001)(46102001)(77982001)(54316002)(19580395003?= =?iso-8859-1?Q?)(83322001)(74416001)(7726001);DIR:OUT;SFP:1101;SCL:1;SRVR?= =?iso-8859-1?Q?:AMXPR07MB056;H:DBXPRD0210HT002.eurprd02.prod.outlook.com;?= =?iso-8859-1?Q?FPR:EC5FD266.A4F29501.F1F11D8A.82D47B59.206A6;MLV:nov;PTR:?= =?iso-8859-1?Q?InfoNoRecords;A:0;MX:1;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/karp/QX2duSpFom7W1CxnfRSqNUk3t-M Cc: karp@ietf.org Subject: Re: [karp] [CCAMP] draft-mahesh-karp-lmp-analysis overflow IPsec X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:40:01 -0000 Picking up on 6), counter overflow, I was thinking that if the aim was to detect a failure in 10ms, then the rate of keepalives is 300/sec for which a 32-bit counter would wrap in several months. Which does not seem terribly insecure or not enough to make an incompatible change to the PDUs so yes, justification needed - like detecting failures in 10microsecond. The thought I had that is still maturing was that the Security Considerations of RFC4204 look good but that they are IPsec-based and I have not had much exposure to IPsec lately. Generally, I do not see much discussion of IPsec and am unsure where the skills exist to evalute that part of this RFC against karp (but perhaps not in either CCAMP or karp WGs). I see no parallel of UDP with IPsec as a starting point within the domain of routing protocols (or much else - I seem to recall having seen Microsoft using that combination). Tom Petch p.s. Still cross-posting pro tem, until directed otherwise. ----- Original Message ----- From: "Adrian Farrel" To: Cc: Sent: Saturday, March 15, 2014 6:30 PM Hi, Tom's review of this document has tipped my guilt index. Here is my brief review. 1. Although LMP is not strictly speaking a routing protocol, I have no objections to an analysis of the security considerations. I do, however, wonder whether RFC 6518 provides the best basis for such an analysis considering how that RFC is tuned towards routing protocols which are a different animal from LMP. I note that LMP is not listed in RFC 6518 although it is in the KARP charter. 2. I don't really think this document does what it sets out to do. Or if it does, it does so in a very round-about way. RFC 6518 Section 4.2 provides a series of steps. I might have expected corresponding sections in this draft. A step-by-step approach would have made cross-checking against RFC 6518 very much easier. 3. I think there is a lot of text in this document that could be pruned. No need to repeat background material on security aims of the IAB. No need to quote extensively from other RFCs when a reference will do. It would be nice to cut this document down to the bare bones so that readers can see the bottom line. 4. Section 2.3 says: "LMP [RFC4204] recommends the use of IPSec for authentication" I think that RFC 4204 is stronger than a recommendation. 5. Section 2.3 says: "That document [RFC 4204] also states that there is currently no requirement that LMP headers or payload be encrypted." I think that Section 15.1 of RFC 4204 is stronger than "currently". 6. Section 2.4 says The 32-bit Message_Id number space is not large enough to guarantee that the Message_Id number will not wrap around within a reasonable long period. Therefore, the system is susceptible to a replay attack. This is a very important statement. (I don't think it falls within the remit of RFC 6518, but it still deserves to be made and considered.) However, there is no analysis of why it is believed that 32 bits are not enough for a "reasonable long period". How often does the author believe that a new Message_Id will be used in normal LMP processing? What is a "reasonable long period"? What are the replay characteristics that would result? 7. Section 2.4 says In addition, LMP does not provide for a generation of a unique monotonically increasing sequence numbers across a failure or a restart. This is partially true. The LMP protocol spec does not require this. On the other hand, the protocol spec does require that a restart be detectable at the remote end. So why does the author believe monotonic increasing is needed over a restart? Compare a restart with a new CC. 8. Section 4 of this document claims to compare against sections 4.1 and 4.2 of RFC 6518. The Abstract only promised to use section 4.2. However, I find it hard to see the comparison with 6518 in the text. 9. The "solutions" in Section 4.1 have me more than a little confused. - "Maintaining Message_Id numbers in stable memory" presumably means non-volatile or persistent storage. This can hardly be a protocol requirement, so let's dig... I think that this is intended to be implementation advice in order to meet the requirement that Message_Id is monotonic increasing even through restart. But I don't see that requirement in RFC 4204 and I don't see it derived in this document. So, while an implementation could do this (and note that 4204 discusses what happens when an LMP implementation can and cannot retain information about a TE link over a restart) I don't see why an implementation would be required to do this. Maybe it is a suggestion that it is OK to give an implementer, but it seems heavy. - Two methods are suggested to seed the Message_Id field after restart. I have two issues with this: - Firstly it goes against the previous suggestion that Message_Id needs to be retained in non-volatile memory over a restart. If you are going to use a clock-based seed then why bother storing the information? - Secondly it assumes that an implementation needs this advice. Well, perhaps it does! But 4204 says nothing about how Message_Id is seeded and it would be a naïf implementer who keeps returning to one when a control channel restarts (or who started at one in the first place). - The final paragraph of 4.1 seems to be trying to say a lot in one paragraph. I see: - There is already a "handshake" defined (presumably you mean Section 8 of RFC 4204) and so the "rollback of Message_Id numbers across a system restart or failure" is not actually an issue that needs attention. - There is a problem with one of the two clock-based mechanisms you suggested in the previous bullet list. Perhaps it would be better to not make the suggestion? 10. Having made a big thing earlier in the document about Message_Id wrapping and the risk from replay attacks, Section 4.1 doesn't suggest any solution (not that I think one is needed). 11. Disappointingly, there is no discussion of key management in the gap analysis section. Does that mean that LMP scores top marks on the KARP scale and needs no further work? All in all, I think the totality of the document boils down to Section 4.1, and I don't see it identifying any specific issues for LMP that need the attention of a protocol team. Of course, this might change if the document gives attention to key management, but I don't think so. Thus, while it is reassuring to have a note of record saying "LMP security seems OK", I don't think we need to make a big thing of it. Thanks, Adrian From nobody Wed Mar 19 09:26:38 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF08E1A07A1; Wed, 19 Mar 2014 09:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-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 Hffs6_V08CGm; Wed, 19 Mar 2014 09:26:22 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 299F31A0754; Wed, 19 Mar 2014 09:26:21 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s2JGQ7UR020563; Wed, 19 Mar 2014 11:26:07 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s2JG6676021908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 12:06:06 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Mar 2014 12:06:06 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 20 Mar 2014 00:06:02 +0800 From: "Bhatia, Manav (Manav)" To: "david.sinicrope@gmail.com" Thread-Topic: [karp] RtgDir review of draft-ietf-mpls-ldp-hello-crypto-auth-02 Thread-Index: AQHOvHW6Vn3yQ7bMNk6chPmRg73d0prpn7xQ Date: Wed, 19 Mar 2014 16:06:01 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B4DAD@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: multipart/alternative; boundary="_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/karp/K5FoTZTytPJvFQUPaYAkNmt69cU Cc: "mpls@ietf.org" , "rtg-dir@ietf.org" , "karp@ietf.org" Subject: [karp] FW: RtgDir review of draft-ietf-mpls-ldp-hello-crypto-auth-02 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 16:26:26 -0000 --_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, I think I have addressed most of your comments and suggestions in the updat= ed document. Can you please take a look at this and see if there is anything else that y= ou think we ought to address before it gets pushed further. URL: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-hel= lo-crypto-auth-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-= crypto-auth/ Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto= -auth-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-hell= o-crypto-auth-03 Cheers, Manav From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Dav= id Sinicrope Sent: Saturday, September 28, 2013 11:25 PM To: mpls@ietf.org; IETF.PWE3; karp@ietf.org Subject: [karp] RtgDir review of draft-ietf-mpls-ldp-hello-crypto-auth-02 This time with a more relevant subject on the email. Dave Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-mpls-ldp-hello-crypto-auth-02 Reviewer: David Sinicrope Review Date: 28 September 2013 IETF LC End Date: 23 September 2013 Intended Status: Standards Track o Summary: I have some major and minor concerns about this document that I think shoul= d be resolved before publication. While I reviewed the document from the R= tgDir point of view, I would strongly suggest a thorough security related r= eview, if not already done, before progressing to publication. In general, I believe the document should be progressed to publication once= the issues are resolved by the authors. The document assumes a working kn= owledge of KARP mechanisms. This should be stated up front with relevant r= eferences. I've attached a .pdf version of the document to this message for use by the= authors. Comments: --- Page 4 --- Note (yellow), Sep 27, 2013, 3:04 PM: Nit: sec1, para 1 1st sentence : c/runs/run Note (yellow), Sep 27, 2013, 3:04 PM: Minor- sec 1, para 2: start the second sentence with "Since the Hello messa= ges are sent with UDP and not TCP..." Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1, para 2: change "Besides a note that some configuration may = help protect against bogus discovery messages, [RFC5036] does not really p= rovide any security mechanism to protect the Hello messages." To "While so= me configuration guidance is given in [RFC5036] to help protect against fal= se discovery messages, it does not provide an explicit security mechanism t= o protect the Hello messages." Note (yellow), Sep 27, 2013, 3:04 PM: Minor - global: c/Spoofing/Falsifying/ Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1, para 3: please give an example of a falsified Hello with a d= ifferent transport address. Note (yellow), Sep 27, 2013, 3:04 PM: Nit - sec 1, para 4: remove first "that" in the fist sentence Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1 para 4, 1st sentence and global: remove "Basic". The text is = introducing a new term of "Basic Hellos" that doesn't exist in RFC 5036. Y= ou may be referring to "Link Hellos". See RFC 5036 sec 2.4. Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1 para 4 & global: remove "Extended" and replace with "Targeted= ". The text is introducing a new term of "Extended Hellos" that doesn't exi= st in RFC 5036. You may be referring to "Targeted Hellos". See RFC 5036 s= ec 2.4. Note (yellow), Sep 27, 2013, 3:04 PM: Nit - sec 1, para 5, sentence 1: c/message/messages/ --- Page 5 --- Note (yellow), Sep 27, 2013, 3:04 PM: Nit - global: refer consistently to "Hello message"s vs "Hellos" and "Hello= packets". Note (yellow), Sep 27, 2013, 3:04 PM: Major - Sec 1, para 6, last sentence: remove thisMinor - sec 1 para 4, 1st = sentence and global: remove "Basic". The text is introducing a new term of = "Basic Hellos" that doesn't exist in RFC 5036. You may be referring to "Li= nk Hellos". See RFC 5036 sec 2.4. last sentence, it is redundant with sect= ion 3. --- Page 6 --- Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 2.1, 1st para: remove 3rd sentence. Adds no value. Note (yellow), Sep 28, 2013, 1:29 PM: Major- s2.2, Auth Key ID: this field is conveying the algorithm AND the the= secret key. It should be atomic, I.e., the algorithm ID should be one fie= ld the key another. Major - s2.2, Auth Key ID: the composition of this field is not clear to th= e casual reader. Exactly how is the algorithm identified and what portion = is the algorithm I'd and what part is the secret key? --- Page 7 --- Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s2.2, p6: remove "really" in the penultimate sentence. Note (yellow), Sep 28, 2013, 1:29 PM: Major - s2.2, p6: what are the "available mechanisms" that are being requir= ed? I.e., if some one was to test compliance to the requirements of this dr= aft what would they test for this? Without more specifics on how to meet t= he sequence number requirement, the strictly increasing requirement in the = paragraph above is sufficient. Note (yellow), Sep 28, 2013, 1:29 PM: Major - s2.3, p1: it should be clearly stated that the high order 32 bits a= re incremented on device boot, and low order 32 bit wrap. "This is curren= tly on given subtly in the previous section as "wrap/boot". Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s2.3, p1: "If by some chance..." Should start a new paragraph, --- Page 8 --- Note (yellow), Sep 28, 2013, 1:29 PM: Major - s3, p1, sentence 1: "... the Auth Key ID maps to the authenticatio= n algorithm and the secret key used to..." Maps how exactly? As noted in = earlier comments it seems as those this field should be broken into two ato= mic fields Auth Algorithm and Auth Key. Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s3, p4: might be easier to see requirements as a list. "Of the above, implementations of this specification: - MUST include support for at least HMAC-SHA-256 - SHOULD include support for HMAC-SHA-1 - MAY include support for HMAC-SHA-384 or HMAC-SHA-512 or both." Note (yellow), Sep 28, 2013, 1:29 PM: Nit- s3,p3:remove this paragraph/list, it is superfluous, with the paragrap= h below and section 2.2 last paragraph. Further the word "includes" implie= s the list is not exhaustive. i.e., I can use MD5 if I wish. Question- s3,p3: Are other authentication hashes prohibited? If not how ar= e they identified and encoded? --- Page 9 --- Note (yellow), Sep 28, 2013, 1:29 PM: Major- s4: this is difficult to follow. - the section makes reference to "the two octet LDP Cryptographic Protocol = ID" this field is not previously mentioned in this document. What is the r= eference to this ID? Where is it defined? - The section makes reference to the "authentication key". Is this the same= as the Authentication Key ID in section 2.2? -"Other protocols using cryptographic authentication as specified herein M= UST similarly append their respective Cryptographic Protocol IDs to their = keys in this step." This document only specifies one protocol using crypt= o authentication, I.e., LDP What are the others being referred to? - This text first uses the term "Cryptographic Protocol ID". What is this? = Where is it defined? From the IANA considerations it is clearer this refe= rs to a KARP mechanism. Please add some explanation of how this mechanism = fits into the KARP framework. - could use more explanation or a reference to additional information on th= e cross protocol attack problem being addressed. - reference to "protocols sharing common keys," what does this mean? Pleas= e elaborate. Perhaps an example would help. --- Page 10 --- Note (yellow), Sep 28, 2013, 1:29 PM: General- the RtgDir Note - s5: I don't see any routing protocol issues with this. It should be= reviewed for security and crypto issues. --- Page 12 --- Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s6.1, p1, 1st sentence: add "the" after "transmitting" Nit - s6.1, p1, last sentence: make this a list Nit - s6.1, p2, 1st sentence: make this a separate paragraph (report generated by GoodReader) --_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 <= /p>

I think I have addressed = most of your comments and suggestions in the updated document.

 <= /p>

Can you please take a loo= k at this and see if there is anything else that you  think we ought t= o address before it gets pushed further.

 <= /p>

URL:       &nb= sp;    http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-hello-crypto-auth-0= 3.txt

Status:       =   https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/=

Htmlized:       http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-03

Diff:       &n= bsp;   http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-hello-crypto-auth-03=

 <= /p>

Cheers, Manav<= /span>

 <= /p>

 <= /p>

From: karp-bou= nces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of David Sinicrope
Sent: Saturday, September 28, 2013 11:25 PM
To: mpls@ietf.org; IETF.PWE3; karp@ietf.org
Subject: [karp] RtgDir review of draft-ietf-mpls-ldp-hello-crypto-au= th-02

 

This time with a more relevant subject on the email.=

Dave

Hello,

I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts as they pass through IETF last call and IESG review. The purpose of the= review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, pl= ease see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it= would be helpful if you could consider them along with any other IETF Last= Call comments that you receive, and strive to resolve them through discuss= ion or by updating the draft.

Document: draft-ietf-mpls-ldp-hello-crypto-auth= -02
Reviewer: David Sinicrope

Review Date: 28 September 2013
IETF LC End Date: 23 September 2013
Intended Status: Standards Track

 

o Summary:
I have some major and minor concerns about this document that I think shoul= d be resolved before publication.  While I reviewed the document from = the RtgDir point of view, I would strongly suggest a thorough security rela= ted review, if not already done, before progressing to publication.  



In general, I believe the document should be progres= sed to publication once the issues are resolved by the authors.  The d= ocument assumes a working knowledge of KARP mechanisms.  This should b= e stated up front with relevant references.



I've attached a .pdf version of the document to this= message for use by the authors.

Comments:


--- Page 4 ---

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit: sec1, para 1 1st sentence : c/runs/run

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor- sec 1, para 2: start the second sentence with "Since the Hello = messages are sent with UDP and not TCP..."

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1, para 2: change "Besides a note that some  configur= ation may help protect against bogus discovery messages,  [RFC5036] do= es not really provide any security mechanism to protect  the Hello mes= sages." To "While some configuration guidance is given in [RFC5036] to help protect against false discovery messages, it does not= provide an explicit security mechanism to protect the Hello messages."= ;

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - global: c/Spoofing/Falsifying/

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1, para 3: please give an example of a falsified Hello with a d= ifferent transport address.

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit - sec 1, para 4: remove first "that" in the fist sentence

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1 para 4, 1st sentence and global: remove "Basic". Th= e text is introducing a new term of "Basic Hellos" that doesn't e= xist in RFC 5036.  You may be referring to "Link Hellos".&nb= sp; See RFC 5036 sec 2.4.

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1 para 4 & global: remove "Extended" and replace = with "Targeted". The text is introducing a new term of "Exte= nded Hellos" that doesn't exist in RFC 5036.  You may be referrin= g to "Targeted Hellos".  See RFC 5036 sec 2.4.

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit - sec 1, para 5, sentence 1: c/message/messages/


--- Page 5 ---

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit - global: refer consistently to "Hello message"s vs "Hel= los" and "Hello packets".

Note (yellow), Sep 27, 2013, 3:04 PM:
Major - Sec 1, para 6, last sentence: remove thisMinor - sec 1 para 4, 1st = sentence and global: remove "Basic". The text is introducing a ne= w term of "Basic Hellos" that doesn't exist in RFC 5036.  Yo= u may be referring to "Link Hellos".  See RFC 5036 sec 2.4. last sentence, it is redundant with section 3.


--- Page 6 ---

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 2.1, 1st para: remove 3rd sentence.  Adds no value.

Note (yellow), Sep 28, 2013, 1:29 PM:
Major- s2.2, Auth Key ID: this field is conveying the algorithm AND the the= secret key.  It should be atomic, I.e., the algorithm ID should be on= e field the key another.

Major - s2.2, Auth Key ID: the composition of this field is not clear to th= e casual reader.  Exactly how is the algorithm identified and what por= tion is the algorithm I'd and what part is the secret key?


--- Page 7 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s2.2, p6: remove "really" in the penultimate sentence.

Note (yellow), Sep 28, 2013, 1:29 PM:
Major - s2.2, p6: what are the "available mechanisms" that are be= ing required? I.e., if some one was to test compliance to the requirements = of this draft what would they test for this?  Without more specifics o= n how to meet the sequence number requirement, the strictly increasing requirement in the paragraph above is sufficient.<= br>
Note (yellow), Sep 28, 2013, 1:29 PM:
Major - s2.3, p1: it should be clearly stated that the high order 32 bits a= re  incremented on device boot, and low order 32 bit wrap.  "= ;This is currently on given subtly in the previous section as "wrap/bo= ot".

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s2.3, p1: "If by some chance..."  Should start a new p= aragraph,


--- Page 8 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Major - s3, p1, sentence 1:  "... the Auth Key ID maps to the aut= hentication algorithm and the secret key used to..."  Maps how ex= actly?  As noted in earlier comments it seems as those this field shou= ld be broken into two atomic fields Auth Algorithm and Auth Key.

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s3, p4: might be easier to see requirements as a list.
"Of the above, implementations of this specification:
- MUST include support for at least HMAC-SHA-256
- SHOULD include support for HMAC-SHA-1
- MAY include support for HMAC-SHA-384 or HMAC-SHA-512 or both."

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit- s3,p3:remove this paragraph/list, it is superfluous, with the paragrap= h below and section 2.2 last paragraph.  Further the word "includ= es" implies the list is not exhaustive.  i.e., I can use MD5 if I= wish.

Question- s3,p3: Are other authentication hashes prohibited?  If not h= ow are they identified and encoded?


--- Page 9 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Major- s4:  this is difficult to follow. 
- the section makes reference to "the two octet LDP Cryptographic Prot= ocol ID" this field is not previously mentioned in this document. = ; What is the reference to this ID? Where is it defined?

- The section makes reference to the "authentication key". Is thi= s the same as the Authentication Key ID in section 2.2?

-"Other protocols  using cryptographic authentication as specifie= d herein MUST similarly  append their respective Cryptographic Protoco= l IDs to their keys in  this step."  This document only spec= ifies one protocol using crypto authentication, I.e., LDP What are the others being referred to? 

- This text first uses the term "Cryptographic Protocol ID". What= is this?  Where is it defined?  From the IANA considerations it = is clearer this refers to a KARP mechanism.  Please add some explanati= on of how this mechanism fits into the KARP framework.

- could use more explanation or a reference to additional information on th= e cross protocol attack problem being addressed.

- reference to "protocols sharing common keys," what does this me= an?  Please elaborate. Perhaps an example would help.


--- Page 10 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
General- the RtgDir

Note - s5: I don't see any routing protocol issues with this.  It shou= ld be reviewed for security and crypto issues.


--- Page 12 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s6.1, p1, 1st sentence: add "the" after "transmitting&= quot;
Nit - s6.1, p1, last sentence: make this a list
Nit - s6.1, p2, 1st sentence: make this a separate paragraph



(report generated by GoodReader)

 

--_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_-- From nobody Thu Mar 20 11:18:14 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D41A0051; Mon, 17 Mar 2014 01:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 AMSpRu8TZwLi; Mon, 17 Mar 2014 01:36:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC9D1A0070; Mon, 17 Mar 2014 01:36:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCD34024; Mon, 17 Mar 2014 08:36:15 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 08:36:15 +0000 Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Mar 2014 08:36:14 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.15]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 17 Mar 2014 16:36:09 +0800 From: Fatai Zhang To: "t.petch" , "ccamp@ietf.org" Thread-Topic: [CCAMP] draft-mahesh-karp-lmp-analysis Thread-Index: AQHPQEziMG4deo3Zq02OTrJxcUbyS5rk9E4A Date: Mon, 17 Mar 2014 08:36:09 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48126ADE36@ESESSMB301.ericsson.se> <09d601cf3a34$373a1ee0$4001a8c0@gateway.2wire.net> <011701cf404c$167fcc40$4001a8c0@gateway.2wire.net> In-Reply-To: <011701cf404c$167fcc40$4001a8c0@gateway.2wire.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/karp/p-z2SlHSn9QJCJAjFgc97wtnhNQ X-Mailman-Approved-At: Thu, 20 Mar 2014 11:18:02 -0700 Cc: "karp@ietf.org" Subject: Re: [karp] [CCAMP] draft-mahesh-karp-lmp-analysis X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 08:36:27 -0000 Hi all, some quick comments from me: Firstly, as we know that all LMP messages are run over UDP with an LMP port= number (except, in some cases, the Test messages, which may be limited by = the transport mechanism for in-band messaging), so what are the special sec= urity requirements needed for LMP compared to the general UDP security? Not= e that I don't see the answer from Section 3. Secondly, is there any security requirement for in-band messaging?=20 Thirdly, for "Gap Analysis" in Section 4, it seems that Message_ID issue is= the only "gap", is there any other "gap"? Best Regards Fatai -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of t.petch Sent: Saturday, March 15, 2014 8:37 PM To: ccamp@ietf.org Cc: karp@ietf.org Subject: [CCAMP] draft-mahesh-karp-lmp-analysis At IETF89, I recall CCAMP was asked if it would review the KARP analysis of LMP and four assented, of which I was one. I would like any discussion to take place on an ietf.org list for its archiving and reliable distribution. I would be interested to hear the views of the other three. My first two thoughts are - Section 1 seems misdirected. KARP categorises routing protocols and one such is TCP point-to-point which encompasses BGP, LDP, PCEP and MSDP but notes in RFC6518, RFC6862 that LDP has an unsecured UDP part which then seems to be neglected. LMP does not seem to fit any category being point-to-point over UDP with mandatory security and indeed seems to be ignored by KARP. So I think that this section needs reworking. - Section 2.5 is a paraphrase of parts of s.7 of RFC4204 which seems to me less clear and less precise - I think that the original text should be used. Tom Petch _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Tue Mar 25 10:32:11 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B91A01E9; Tue, 25 Mar 2014 10:31:57 -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, 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 hd4mFZbSjU3y; Tue, 25 Mar 2014 10:31:56 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A356B1A019F; Tue, 25 Mar 2014 10:31:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CDA1B1621FB; Tue, 25 Mar 2014 10:31:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-57.clppva.east.verizon.net [70.106.134.57]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 384A01621F4; Tue, 25 Mar 2014 10:31:55 -0700 (PDT) Message-ID: <5331BD89.5090802@joelhalpern.com> Date: Tue, 25 Mar 2014 13:31:53 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" References: <5331548F.10409@pi.nu> In-Reply-To: <5331548F.10409@pi.nu> X-Forwarded-Message-Id: <5331548F.10409@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/karp/xnmJDodcXz33hHJnjCvxI3S5ZJA Subject: [karp] Fwd: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:31:58 -0000 For yoru information, the link below is to a presentation Adrian gave to the MPLS working group on producing drafts that are going to RFC. Some of the thoughts are specific to MPLS. But most of them are widely applicable. Yours, Joel http://www.ietf.org/proceedings/89/slides/slides-89-mpls-15.pptx From nobody Fri Mar 28 11:13:19 2014 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C1A1A094C for ; Fri, 28 Mar 2014 11:13:17 -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_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 tN21q9X8wlS9 for ; Fri, 28 Mar 2014 11:13:16 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id CF34B1A0332 for ; Fri, 28 Mar 2014 11:13:15 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-77-5335b8d2a94e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 03.33.11484.2D8B5335; Fri, 28 Mar 2014 19:00:50 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Fri, 28 Mar 2014 14:13:13 -0400 From: Uma Chunduri To: "Joel M. Halpern" , "karp@ietf.org" Thread-Topic: [karp] Fwd: Routing Area meeting draft minutes Thread-Index: AQHPP8uvMcipb4euy0mUVHZoiYFZuZr24i/Q Date: Fri, 28 Mar 2014 18:13:12 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F23170C@eusaamb105.ericsson.se> References: <5323735A.4080908@joelhalpern.com> In-Reply-To: <5323735A.4080908@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPiO6lHabBBg1tShYfT71hstj7bQ2j A5PHkiU/mTzOTfnOGMAUxWWTkpqTWZZapG+XwJWxZ/4q5oIFPBUnZ9xkbWB8y9nFyMkhIWAi ce3zM0YIW0ziwr31bF2MXBxCAkcYJW7vns8C4SxnlPjwog2sik1AT+Lj1J/sXYwcHCICPhJr /saBhIUFrCVWtT1gA7FFBGwkmnZcY4GwjSR2zTgOZrMIqEp8Xv+YCcTmFfCVuH7kC1hcSKBO YtfhiawgNqeAvsTko5eZQWxGoIO+n1oDVs8sIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaU 2Nc/nR2iXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYOUqL U8ty040MNzECo+GYBJvjDsYFnywPMUpzsCiJ83556xwkJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgTFYX6D8bUGIw9aMhlOaK4z3Xt2Qz7zHaZ/9zaC708pybDf+dTkVfsrHO8//v9k+I75r fI/PJ3ecXXiAd1XcxW1xjYXpWiIrvZ0Vb7Z4zHBTqdxs92v12QPndBc/y5l4WWZb+H6XPz/X /QntuvWV+bnoiQ3dU+4s/NNQ68bInr/7ydUX9mp+OrpKLMUZiYZazEXFiQBqAfEbVAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/karp/u2jX8Qz-llxrY2DcZSiZvOJHQ60 Subject: Re: [karp] Fwd: Routing Area meeting draft minutes X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:13:17 -0000 Dear Chairs, Thanks for sharing this. Goo discussion. =3D=3D=3D=3D=3D=3D=3D=3D=3D Joel - how many people here would like to see work go forward on auto manag= ed keys for interdomain? Good show of hands. On intra domain? Less hands. How many would do work on interdomain? - only 6 hands. Intradomain? - only = 6 hands. So this is the problem. Lots of people want the work, but not do work. So again, how many would help do the work w= ith interdomain - this time a few more hands. For intra domain? only again about 7. Thank you - we will try and figure out what to do with this. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Do chairs considering any further actions on how WG should proceed on pendi= ng items? -- Uma C. -----Original Message----- From: karp [mailto:karp-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, March 14, 2014 2:24 PM To: karp@ietf.org Subject: [karp] Fwd: Routing Area meeting draft minutes Minutes from the KARP session on AKM can be found at the bottom of these (t= hanks Deborah). Please read them, as Brian and I hope to start followup on= the list soon. Yours, Joel -------- Original Message -------- Subject: Routing Area meeting draft minutes Date: Fri, 14 Mar 2014 20:57:24 +0000 From: BRUNGARD, DEBORAH A To: routing-discussion@ietf.org Hi, Draft minutes are uploaded at: _http://www.ietf.org/proceedings/89/minutes/minutes-89-rtgarea_ Thanks to all who provided Working Group summaries. Comments welcome. Deborah