Re: [karp] [CCAMP] draft-mahesh-karp-lmp-analysis overflow IPsec
t.petch <ietfc@btconnect.com> Mon, 17 March 2014 10:40 UTC
Return-Path: <ietfc@btconnect.com>
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" <ietfc@btconnect.com>
To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ietf.org
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: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51444003)(164054003)(13464003)(199002)(189002)(95416001)(81342001)(69226001)(20776003)(81542001)(47776003)(84392001)(95666003)(80022001)(66066001)(92566001)(33646001)(50466002)(74876001)(92726001)(74706001)(65816001)(74366001)(4396001)(74502001)(47446002)(31966008)(74662001)(94946001)(63696002)(85306002)(97186001)(93136001)(44736004)(93516002)(94316002)(93916002)(97336001)(47736001)(47976001)(50986001)(49866001)(86362001)(50226001)(80976001)(23756003)(42186004)(51856001)(14496001)(53806001)(87976001)(79102001)(61296002)(76786001)(90146001)(44716002)(77156001)(62236002)(76796001)(83072002)(77096001)(62966002)(85852003)(87286001)(87266001)(76482001)(56816005)(56776001)(19580405001)(88136002)(59766001)(89996001)(46102001)(77982001)(54316002)(19580395003)(83322001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB056; H:DBXPRD0210HT002.eurprd02.prod.outlook.com; FPR:EC5FD266.A4F29501.F1F11D8A.82D47B59.206A6; MLV:nov; PTR: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 <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp/>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=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" <adrian@olddog.co.uk> To: <ccamp@ietf.org> Cc: <karp@ietf.org> 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