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

"Joel M. Halpern" <> Sat, 24 September 2016 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C35B12B01C; Sat, 24 Sep 2016 12:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DqPDq4YoPJvp; Sat, 24 Sep 2016 12:11:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F18812B025; Sat, 24 Sep 2016 12:11:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 448431C5B87; Sat, 24 Sep 2016 12:11:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1474744310; bh=r7jR4Eo0KK8c9uaJcegv9cIey/7bhGzGIE+aBTCBT+Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cUsKO8iRV8DRLCCzZfujKltI7e8L4Dpvg+Yw/g7V3c0NFDVg/BwMKd7kGBwvHLqLH Fxqh0tPchJiPbofdm4WmscwFIeU6052gGu4XzrZTZ07qDCLZs863BLBjtFoMgO/JFB 15pisZ7ZDnTeAOstxEMBEXu6yENn1SAEj/V9JDc0=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 927071C031A; Sat, 24 Sep 2016 12:11:49 -0700 (PDT)
To: David Mandelberg <>,,,
References: <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Sat, 24 Sep 2016 15:13:15 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
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, 24 Sep 2016 19:11:52 -0000

As I understand it, the multiple representations are deliberate.  I do 
think we should add a little text in the security considerations section 
noting that the representation has to be preserved if the information is 

Your comment on the algorithm ID in section 4.7 seems cogent.  I will 
let the authors respond.

On 9/24/16 2:53 PM, David Mandelberg wrote:
> 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.