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

David Mandelberg <> Sat, 01 October 2016 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF24812B08E for <>; Sat, 1 Oct 2016 10:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lDMUkNqeV2Xf for <>; Sat, 1 Oct 2016 10:28:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1852E12B0D2 for <>; Sat, 1 Oct 2016 10:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1475342893; bh=MgIRmy2zn3lKVqxWat1HazMiEul34A2kXe6Yen4h90E=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=aKzyk9ncuxtcJ3TRFVn5R3nLj880LSQGQYOV4WH5/XfXDIBZAYgWDG2IgyuzOvFAUtZxjKmOZw+Db9AQcTcuZz4U0LG2ii5KNw9Dwf8z2bET2Afu5LR/21hRvNU5kyFPt8ymV0+Iy1IKe3WUnO2RiwIgmnkyIHHUN/NTo54g3tmvciT9r6TI+PxJszBvmtEjucg1zaeQgmuXzdEg1fvxio95b70eD/eEMX1SfgdSi7AtZVluRS997ZjYS8xZWPszswhKcNPi2TaUaCSo2p72ToSR9udcOiyQJjfIMiO0GdAfgwJlKjKdlSfrmKMcDFm6qXJI2O4ZgKvBiVqkZfj5jA==
Received: from [] by with NNFMP; 01 Oct 2016 17:28:13 -0000
Received: from [] by with NNFMP; 01 Oct 2016 17:28:13 -0000
Received: from [] by with NNFMP; 01 Oct 2016 17:28:01 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: X8wlMcQVM1lYiySuTrPif.nUpwyv9M7Zc8hVkOBypH6f3QS m4AeFw_YQVEO7aR1s2ffuQGfrYVLZN5q_pgVvQGzrwzN.9rexWIvACIDkeSc .2fzpY1IwLmNv.7pnBtoKL0tF1PQSqyFk8gtTff9.1JEnsSVenwXTQxU1eFT htf84AeojLCecVH5iA7bteLDINJhEFhXYvtjcoiw1.jasrH0Ny_J0DLj0fvn HAssjfr1q.zGIAQ3MEAWK4zjLVa3VS9abqGEilQWPqp7GVUG7cm0blEQHkL2 75RYvD3vJJfSwGglkiHXDtIWPSmrIqu9AgF9HUtOlvq5Eqmt_6m.T3C.Z6AE hC.owusi14A_bqEKzpPpeV226DoZ4bW6XFrtFpXsnXZ.HW5t8WZEY93RyReY PqWLG_hP.6MrsH9v9jl_TUxPuVZvMobeWSDxAIzgj3m0t5_AAYgsomJMRwJc 04kk8_JXxnNemiVYDHkawhxPlkKAZ_TaayjKaop9d5R4luh0uh7w5NL.SkVJ ezd_XLb2eGbBJWmO3ClvRot7DfqNYgLEz8pUqB1Uwy3j9olKomg--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from [] ( []) by (Postfix) with ESMTPSA id 35B9B1C603B; Sat, 1 Oct 2016 13:28:11 -0400 (EDT)
To: Dino Farinacci <>
References: <> <> <> <>
From: David Mandelberg <>
Message-ID: <>
Date: Sat, 01 Oct 2016 13:28:06 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="Dwt6pnwnVhVDHhDEFwkQf4t99BkeVj9b6"
Archived-At: <>
Cc: The IESG <>,,
Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 01 Oct 2016 17:28:17 -0000

On 09/26/2016 12:43 PM, Dino Farinacci wrote:
>> On 09/25/2016 06:15 PM, Dino Farinacci wrote:
>>>> 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?
>>> No not for security purposes. There are multiple ways because we allow some nesting of information as well as allow for compatibility for older implementations that can’t parse some AFIs and LCAFs but is required to parse the AFI-List LCAF type.
>> Ok, then I think it needs to be made clear in the security
>> considerations that this format cannot be relied on to have no more than
>> one representation for the same information.
> Sorry, I am not following your point. The nesting procuedure of LCAFs allow the same type of address to be expressed multiple ways. I can’t tell from your commentary if this is a good thing for security or a bad thing. So please provide some suggested text on what you would like to see in the Security Considerations section.

Ok, here's what I'd like to see. (But remember that this is just a
suggestion. From the SecDir boilerplate: "Document editors and WG chairs
should treat these comments just like any other last call comments.")

It is possible to encode the same address in multiple ways using LCAF.
For example, the IPv4 address can be encoded as "AFI=1,", "AFI=LCAF, lcaf-type=AFI-list, AFI=1,", or
"AFI=LCAF, lcaf-type=AFI-list, AFI=1,, AFI=0". This means that
systems that use LCAF must not assume that two distinct strings of bytes
are distinct LCAF addresses. Additionally, if an LCAF address is
digitally signed or MACed, the specific encoding of the address must be
preserved in order for the signature or MAC to be valid on receipt.

David Eric Mandelberg / dseomn