[secdir] secdir review of draft-ietf-lisp-lcaf-15

David Mandelberg <david@mandelberg.org> Sat, 24 September 2016 18:53 UTC

Return-Path: <david@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A12F12B025 for <secdir@ietfa.amsl.com>; Sat, 24 Sep 2016 11:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 vcdyvqmAgvFb for <secdir@ietfa.amsl.com>; Sat, 24 Sep 2016 11:53:31 -0700 (PDT)
Received: from nm6-vm3.access.bullet.mail.bf1.yahoo.com (nm6-vm3.access.bullet.mail.bf1.yahoo.com [216.109.114.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7401112B027 for <secdir@ietf.org>; Sat, 24 Sep 2016 11:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474743208; bh=ctB9D+43zKgfQRaOIUOAp3vHsOC8KMQ6Aa+czouNiws=; h=To:From:Subject:Date:From:Subject; b=hAdTfjJ3hoVduonfkOZhQ7YsS/IGwSpbwYMN5AQAv8xQ8p6WdfT+iITko5jRrab5QRWKHttN4+0eRjnBhO/Bx/0uvCKF+ZOSBX/teBm6HAm4SCyg+AxSn2tL5GtC8OkkvwphQE3VJH/f/q6VxH+WCXRk3dhcT3+h6Cavt8pfvQpnbsu7ivEGnW2l6OwQLJZUXXvo0KMuU/HjSA6ocg4CNNPaoEqeKc7aWt1EYkJRKl7EY2MamwOFfgmYDoIAiaFocV/NBFQwvXEpAdOmbIuz0P7yD5PeEHKpHbFzK5dO8FCpk5m/PMvbb8ZNw/qkZbDXFjcwd1bbLlzobsb/Byn7cw==
Received: from [66.196.81.161] by nm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2016 18:53:28 -0000
Received: from [98.138.226.244] by tm7.access.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2016 18:53:28 -0000
Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 24 Sep 2016 18:53:28 -0000
X-Yahoo-Newman-Id: 780553.12739.bm@smtp115.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: SlvL690VM1m4E1wmHLvbtHK6.0Lwgo9SPkt82yeuYQu0D4Y RnKVQq216WmLGH0xzaVHOy..2aEYp.G.DNFdC9tiXQQvLamQVmXnWjLaDcBY teHFne9nN_Fyi6ryFv0i1_4W6c3eTgtWF9pZTdRY6KHtNyb_Vot3JLb.IEnC BhgO_o32N.86qC0w6XvRB7b82QaVnbslKkht4PpdpIq_LQOTOSVL8JHls4_q 4dpoJlk_czdu_4wy_4LRNRllHVAzSi58GH8HL_uFtLK6dVn91gQnb7Kyy5J9 hqUQEj187Bs8MXhQjS7Ep7jxhoWz8Lf_fw1mx5C8vOJJ8joGXSy9TFdp7A0i lbjYC3Pe04oA1pedvDiwejEqWsISH2m7rwOr1tzpo64KmBvcUXC30KClAJJ4 BAy1iLxz.VOrwOBtndiPGzF7GxttJcvcdG9Zvrw_zJ7ppiGtBrFBwtI.accg ZMOnYOy5zmx_BM.tc_.f6nERvtwJc_Mgnn7xnW5KWVrb6yL61DEK3zReDK9a taNlEd3vYVOqiDuA7D_fTI.rwb_OBXWFaRZnFOUwhlFuXieBV_jNeZU.iDlR 7K5YplrnRxa1dpTmimtYIxvS5bQ--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 981251C6045; Sat, 24 Sep 2016 14:53:27 -0400 (EDT)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org
From: David Mandelberg <david@mandelberg.org>
Message-ID: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org>
Date: Sat, 24 Sep 2016 14:53:23 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DwSatSTx3v4Md3nGMrjvq2XPwHSdAhn09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9Ek2CMK66yEyLf918ryXdPmeaHg>
Subject: [secdir] secdir review of draft-ietf-lisp-lcaf-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Sep 2016 18:53:32 -0000

Hi,

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

I found one issue in various parts of the document (described below),
but I'm not sure it's relevant to security. If it is, then I think this
document is Almost Ready. If not, then I think this document is Ready
With Nits.

There are multiple places in the document where it's possible to encode
semantically equivalent information in multiple ways, despite the word
"canonical" being in the title of the document. Is there anything that
relies on these addresses being canonical for security purposes?

Multiple places in the document (sections 4.1, 4.5, and 4.8) specify
mask lengths, but do not specify that the masked out bits MUST be set to
zero.

Section 4.4: The description of RTR RLOC Address gives two different
ways to encode an address with zero RTRs.

Section 4.10.5: If I understand the compatibility mode correctly, this
explicitly creates a second way to encode a semantically identical address.

Section 5.4: There are many different ways to encode equivalent JSON
data here.

Section 6 (Security Considerations): There is no discussion of these
addresses being canonical, and what other systems might or might not
rely on these addresses being canonical.


I also have some questions/nits:

Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also include
the RLOC-address or LCAF payload?

Section 4.3: Altitude is described as a signed integer, but this
document doesn't specify the encoding. I assume it's two's complement,
but that should probably be made explicit.

Section 4.7: The Key Count description talks about "Key sections," but
doesn't say which fields are part of the key section (and can thus be
repeated). I have a guess which fields are part of the key section, but
it's not entirely clear.

Section 4.7: The Key Algorithm description doesn't point to a registry
of valid values or otherwise say how to interpret values in that field.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/