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

David Mandelberg <david@mandelberg.org> Wed, 28 September 2016 02:01 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 48B9512B3B0 for <secdir@ietfa.amsl.com>; Tue, 27 Sep 2016 19:01:40 -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 eXjz3zjIs48S for <secdir@ietfa.amsl.com>; Tue, 27 Sep 2016 19:01:38 -0700 (PDT)
Received: from nm18.access.bullet.mail.bf1.yahoo.com (nm18.access.bullet.mail.bf1.yahoo.com [216.109.114.41]) (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 134D612B502 for <secdir@ietf.org>; Tue, 27 Sep 2016 19:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475028095; bh=6n6HTVMRyVCHX4zw9Deg15lIuzTFbiAOQVfRYIVnVdI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=LEK6sOm3I2/nPPxf5e+ujE/RUHJui+wnA4EA9sxBACiUutYeJYhSrWogf3LNEp/L+CiwoluHxI0/ZsZ12sjfoizq34E1Ab5CyJGi9viwtfOJ1Tw6/FJXMxbRSjwplf5huzfLq9/RVxmRIUghxAQ6D5kibTgy73aL1eCAZnYZScA6q1Mh8hj31ZFTlF8IN4EVgP4HC9362XRMjaY48Dipr+xqHw220sjHaDg8LglDyglOOw8BWW2efFEhgkFpIhw25ENNSv2C7u6oNCvx6vc5Ho/1xDX6Pn1/B07lcWIZz1qecoPmQD+JFNKYmmOob/LWR/hF7J3w+NXVXp6+oqx+Jg==
Received: from [66.196.81.156] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2016 02:01:35 -0000
Received: from [98.138.104.97] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2016 02:01:35 -0000
Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 28 Sep 2016 02:01:35 -0000
X-Yahoo-Newman-Id: 18211.45320.bm@smtp117.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: gI37KBQVM1mE5ng.HyiIgIw1llVl0ch_979uVBU2zyhxhyp rWS27QzR9nDnTXFhrxgfAnwHzR_0n3HBFaxHrdQpALuR9uGBVvn4gmssSD7n WsIRJpDkINVzxQ.on1X5hgxAB_ptzTZKRCqCXXOwlAOJekGuwsT2YY5FEP6P iCZIOGpk41CN_Bid_t0OHURxZzg2Y5MAhO0uOEqYc4zxL2qxmgAB1jmk.zsu NKdJxtsJJdxhPps2Af_3yeWawL.0Od5raxTpHBfSlzZ9.iop46GJhc2Sk3_V bwnBVYns8wn_4PgdGCJszcpqOvpWLwFWx.ulaQ2O000JatP20E7XdjP4omVg aW9YrS9QUuxueuOTmBRhL4mDQ3DY.pMnZApU6URJ6qR2k.DU1wJYcieZVXKl NVhiU_L3fGSYCWUp56g.p3BX.xWYRGi9DuPfqz1uk8NVS2RzE7Q.aGGXC9Iq 4oExumy6TregDVEpeIFeNyq0cSQOnOAOgNEKliK7KudkCmk_gFetQY34Wgtn rUTnizQJUzdayYzYlMr8RtsBQLKXrwdURFI_sEarR.l.uj3chV1KrZoIIgwd MpACF.QcEiho-
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from secure.mandelberg.org (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 E095A1C6033; Tue, 27 Sep 2016 22:01:32 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Date: Tue, 27 Sep 2016 21:01:32 -0500
From: David Mandelberg <david@mandelberg.org>
To: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <2979E792-737A-4027-8B79-7080AB533B9B@gmail.com>
References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com> <cea887fa-f076-2ada-c9c8-fce548dccfca@mandelberg.org> <D896C233-1414-4635-9DE3-FE10A7BF1E69@gmail.com> <2979E792-737A-4027-8B79-7080AB533B9B@gmail.com>
Message-ID: <7d3bf4f189851bcc12b4f659af5b983a@mail.mandelberg.org>
X-Sender: david@mandelberg.org
User-Agent: Roundcube Webmail/1.1.5
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/nIx3k_YdiZf7B8QzcKFhzVnzp_s>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org
Subject: Re: [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: Wed, 28 Sep 2016 02:01:40 -0000

Sorry, I'm busy with my dayjob. I don't think I'll have time to get to 
this until the weekend.

On 2016-09-27 11:50, Dino Farinacci wrote:
> David, any response. Thanks.
> 
> Dino
> 
>> On Sep 26, 2016, at 9:43 AM, Dino Farinacci <farinacci@gmail.com> 
>> 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.
>> 
>>> IESG: This means that I think this document is Ready With Nits.
>>> 
>>> 
>>>>> 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.
>>>> 
>>>> Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. 
>>>> And in 4.1:
>>>> 
>>>> IID mask-len:  if the AFI is set to 0, then this format is not
>>>>     encoding an extended EID-prefix but rather an instance-ID range
>>>>     where the 'IID mask-len' indicates the number of high-order bits
>>>>     used in the Instance ID field for the range.
>>>> 
>>>> It is clear that the high-order bits are used that cover the 
>>>> mask-length and the low-order bits are ignored. Is this not clear to 
>>>> you?
>>> 
>>> That part is clear to me. I just meant that the document as written
>>> appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the
>> 
>> I will make this more clear. I added some text.
>> 
>>>> 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.
>>>> 
>>>> In this respect “canonical” is relative to how LISP defines to 
>>>> encode both simple AFI encoded addresses or more complex/flexible 
>>>> addresses that accompany information.
>>> 
>>> Ok. I interpreted canonical to be a security property of the 
>>> addresses,
>>> i.e., that if two addresses are not bytewise equal, then they must 
>>> not
>>> have the same meaning. If that's not what you meant by canonical, 
>>> then I
>>> think the security considerations should say that, so that nobody 
>>> tries
>>> to rely on that property in the future.
>> 
>> Canonical in this spec means semantically canonical. That is the 
>> following two IP addresses are equal:
>> 
>> AFI=1, 1.1.1.1
>> AFI=LCAF, lcaf-type=AFI-list, AFI=1, 1.1.1.1
>> 
>>>> 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.
>>>> 
>>>> We have put that in a use-case document. This Security Key LCAF is 
>>>> used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In 
>>>> the lisp-crypto document we have a registry for cipher suites used.
>>> 
>>> Should this document reference one or both of those documents?
>> 
>> I added text to reference the two documents that use this Security Key 
>> LCAF Type.
>> 
>> I’ll post a new draft when you get me some text for the Security 
>> Considerations section. Thanks!
>> 
>> Dino
>> 
>>> 
>>> 
>>> --
>>> David Eric Mandelberg / dseomn
>>> http://david.mandelberg.org/
>>> 
>> 

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