[mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth
"Adrian Farrel" <adrian@olddog.co.uk> Sun, 13 April 2014 18:10 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C979A1A01FF for <mpls@ietfa.amsl.com>; Sun, 13 Apr 2014 11:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Level:
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN7_urHZpQo9 for <mpls@ietfa.amsl.com>; Sun, 13 Apr 2014 11:10:53 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id D92351A020F for <mpls@ietf.org>; Sun, 13 Apr 2014 11:10:50 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3DIAlME011684; Sun, 13 Apr 2014 19:10:47 +0100
Received: from 950129200 (customer908.105.wv.cust.t-mobile.co.uk [178.105.3.139] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3DIAjNf011666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 Apr 2014 19:10:46 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org
Date: Sun, 13 Apr 2014 19:10:44 +0100
Message-ID: <002301cf5743$b1a74af0$14f5e0d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac9XQ4qnttK65JrbStiwuG/j7ZBucw==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20630.001
X-TM-AS-Result: No--11.865-10.0-31-10
X-imss-scan-details: No--11.865-10.0-31-10
X-TMASE-MatchedRID: uM/FAQ+OoQenykMun0J1wnBRIrj8R47FJPNIV6GF8mtX14Hy+eYp70no Eo7WwNxnJKelhEebHIqIY102U/vYqLXIiX0OZIOabMGKOuLn5FUfXzVgO0hVqgDqzaYhcjeQboG JPDpzSEn90TkpI5Gh2pnmteZltT2lhzsX7/vYqPCeEco05hssvpZ6zKu0q4rt/LmQOavvaE2Pp7 xHKEBR4kBfeAaFhRvEYklZyHW6Io80Z9sXcK7F6biMC5wdwKqdLOOFU9c9B/i/7bplhbPCQggZ9 1sE6DJjvdPbwgcKBFHLi4BEWxALS3bOInuIcg6/YD9XTRdaMO2Vq+okl1rYD23D6f6IpbLIj9Fj +RtK2eDAv6Yogn/PGYpBtjH4AF7SSqSDOjH8JBprRpSjNebQNuAAYRasBjMex4FVLO4NFrDfl0P vqvMF9xWX2qCWKuyr7qXXLN2XZ6rTpWeic52qPLThj82FPFSCO1K5iM8Q6KC0rcU5V/oSe8uFW1 3cxnvTtz2oIRmoEs/mDTS+93LoejcpdZ3fQiLdOX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAqr jYtFiRGmTunxbRYa1Zp3OFd2gwGs3YuIzwR6kX5W2zZKWc9/X7cGd19dSFd
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/BNCPqZ2-ITqo5G__RDVkQKEzvxI
Cc: mpls@ietf.org
Subject: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Apr 2014 18:10:56 -0000
Hi authors, Thanks for progressing with this document. It is good to see security being taken seriously by the WG. I have done my usual AD review after receiving the publication request. This has led me to a small number of issues and questions, below. It would be nice to see these addressed, but I am open to discussion including the authors and WG saying that I am wrong or that the additions are out of scope. Thanks for your work, Adrian === I think that the threat analysis is a bit thin. As with all interior routing protocols, there seem to be two possibilities. The first is that a bad LDP message is admitted (directly or through a tunnel) into the network. The second is that there is a bad actor in the network. It would help if the document was a little clearer about which attacks it is defending against and why normal protection at the edge of the network is not considered enough for the former, and why a bad actor within the network would waste its time attacking LDP when there is so much else it can do! --- IANA stuff... Section 2.1 should use "TBD1" and Section 2..3 and 8 should be similarly updated to identify the new Cryptographic Authentication TLV. The back reference in section 8 should presumably say "2.3" not "3.2". --- Section 2.1 has The Cryptographic Authentication TLV Encoding is described in section 2.2. I think this should read 2.3. --- Section 2.2. o Security Association Identifier (SA ID) This is a 32-bit unsigned integer used to uniquely identify an LDP SA, as manually configured by the network operator. "Unique" in what scope? Presumably "globally unique" is not needed. I am also concerned by the requirement for manual configuration because that is open to error and attack. Each LDP speaker will have an SA with each of its peers and each peer must have the same SA ID for communication to work. If you are going to go to this extent, it seems like you don't actually need Hellos to do discovery and you will only use them for "keepalive" in which case, it might be better to replace that second aspect of the Hello with something like a KeepAlive message! It is perhaps ironic that part of the reasoning you apply against access lists is the resources they take up on each LSR, yet you are requesting that each peer that is allowed to communicate has an SA configured which seems to me to be more resources than a simple access list. Is there no way to generate the AD ID value from other known information or the LDP session? Perhaps this concern is best addressed by writing a Management Considerations section to describe: - what needs to be configurable in an implementation - what needs to be configured per SA - what needs to be made available for inspection - what logging takes place --- There is a small alignment error in the figure in Section 2.3 --- Section 4 is a little odd. The implication of the wording is that this document sets requirements on all implementations of all other protocols that use cryptographic authentication. I would suggest deleting the whole section and updating Section 5 as follows... OLD Ks is a Protocol Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet LDP Cryptographic Protocol ID appended. NEW Ks is a Protocol Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet LDP Cryptographic Protocol ID TBD2 (to be defined by IANA) from the "Authentication Cryptographic Protocol ID" registry. Ks is used to mitigate cross- protocol attacks when multiple protocols share a common key. END --- Section 6.2 if the locally computed Hash is not equal to the received value of the Authentication Data field, the received packet MUST be discarded, and an error event SHOULD be logged. It is customary to give some warning about rate limiting logging because logging usually takes more resources than receiving packets, so if you are subject to a storm of bad Hellos you could die trying to log them.
- [mpls] AD review of draft-ietf-mpls-ldp-hello-cry… Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-ldp-hello… Loa Andersson
- Re: [mpls] AD review of draft-ietf-mpls-ldp-hello… Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-ldp-hello… Loa Andersson
- Re: [mpls] AD review of draft-ietf-mpls-ldp-hello… Adrian Farrel
- Re: [mpls] AD review of draft-ietf-mpls-ldp-hello… Vero Zheng
- Re: [mpls] AD review of draft-ietf-mpls-ldp-hello… Adrian Farrel