Re: [karp] [CCAMP] draft-mahesh-karp-lmp-analysis
"Adrian Farrel" <adrian@olddog.co.uk> Sat, 15 March 2014 18:31 UTC
Return-Path: <adrian@olddog.co.uk>
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" <adrian@olddog.co.uk>
To: <ccamp@ietf.org>
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 <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: 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 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 > -----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 > > 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