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

Dino Farinacci <farinacci@gmail.com> Wed, 28 September 2016 02:06 UTC

Return-Path: <farinacci@gmail.com>
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 E248012B3AC; Tue, 27 Sep 2016 19:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CSKT9aFRehkv; Tue, 27 Sep 2016 19:06:16 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 1400412B3A2; Tue, 27 Sep 2016 19:06:16 -0700 (PDT)
Received: by mail-pa0-x233.google.com with SMTP id qn7so11251158pac.3; Tue, 27 Sep 2016 19:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PkfTOC8DTt/zI52PQ1D7fX1X6XTlgNlP4N7H9+i7md0=; b=oesHVNUp5XFuGE7C2ZPV4yBWHAZmXCiIEBgVs7lYtiIMZsYDho+19diq5Zo5ftD5Q0 PK0GSpFz9SXZr/uiDIrDhstOftBLgGrhfuTYRwQBK+c+1Vw1n9Fg7E/SkDvvHMjXOoIG 4t/3pnIHrMdevx/0DCPLVx9o4lU7yn2+dA5FRIISbGC4YQ1WYl4Feec8eoJcBqtQ+IjX UsQzPvUSHZHdYa4TRPXwpS3Q+opiNG0hSIf6sBxxOlunvQU7nyFSpf3jBwHFhuip6xrl 6E6frdHYveQrOhTHWtW/XqaOvXXfiDWVWHgmxcm+sJwTGtQSXmKoC07BubyeStXOz2JC 7Mkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PkfTOC8DTt/zI52PQ1D7fX1X6XTlgNlP4N7H9+i7md0=; b=hUvVVkn3l1R7lgV57bBkHM0njUzWI76FJLhOlBQ/irpz6fIhif1q/tpZZ7JJXu9qxn Q+VIApVx6Xf38DBNjTSnfblmKqW6f6JfXzORw1pLEd3A6M85pVS9RKJIIIgjVDvEpkJY x0pSd8DA+zjT+3sZ1M/x3T476arvl8fKBR2SJMdPSUevg+IGt1A7F8TPMT1CIuK0bl0w nfUxBDn9pcvqV25xIDTwAgv0JNzjbaXiOq9WI4Wpi0hSNr1hZJyw5pKYq5SM15JqbCM5 J/Rt/UzzMzkxSBZonno0xTQtXHx9XBpbL+Nbgg7p+witTMOu89Qbf3AmGDD/krSMoTca pVMA==
X-Gm-Message-State: AE9vXwPYS98f4e1JEU9maKcYwqa44dXsZPbu8RiQxIhcjb7YCpPCnCX0Ypgw9Yu3DyHp6w==
X-Received: by 10.67.23.201 with SMTP id ic9mr52728426pad.143.1475028375594; Tue, 27 Sep 2016 19:06:15 -0700 (PDT)
Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by smtp.gmail.com with ESMTPSA id sa1sm7683205pac.34.2016.09.27.19.06.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 Sep 2016 19:06:15 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <7d3bf4f189851bcc12b4f659af5b983a@mail.mandelberg.org>
Date: Tue, 27 Sep 2016 19:06:12 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A32D7455-369D-4D8D-898B-D46C2C3633B4@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> <7d3bf4f189851bcc12b4f659af5b983a@mail.mandelberg.org>
To: David Mandelberg <david@mandelberg.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/53nsUYUVWTaBpTI8S6Ur3zS52y8>
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:06:18 -0000

No prob David. Thanks for letting me know a rough ETA.

Dino

> On Sep 27, 2016, at 7:01 PM, David Mandelberg <david@mandelberg.org> wrote:
> 
> 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/