Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07

Dino Farinacci <farinacci@gmail.com> Sun, 25 September 2016 21:37 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 0829712B01F; Sun, 25 Sep 2016 14:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level:
X-Spam-Status: No, score=-1.298 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, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 lcHKIRv_c9Bx; Sun, 25 Sep 2016 14:37:51 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 21EBA12B03C; Sun, 25 Sep 2016 14:37:49 -0700 (PDT)
Received: by mail-pa0-x22b.google.com with SMTP id qn7so38456000pac.3; Sun, 25 Sep 2016 14:37:49 -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:message-id:references :to; bh=zlCl7CPkR3JE/qFRMSkbdPR9LQSCNqQkG+ewcxOchjU=; b=StKsnneVwQLPLg/a54yszkaIt8v9ZJ+McB0fFuKkwEAxKFXThD1o/0w2NKcAuA6b9D aOHDm7W6GosP0XX0hcQQCa5ihzdmSw9IPnZUkhOKTl4qlay/AfcoJzMKTRDneLkktg3j 0cT5NGHotfNBSYfttuPEzF8ICLRRHrYerteMQkNZG3py0riKYOHaa9mGnXO93KvwG+Kw 8x+VcfAsOK60/uRgr/cNLGwZEqbXc/2MfypNKOcJIY+XiLgv5aMVnfZ8uyr5xZE/4TNC gjvVuOGL/+oJkc8REjk/owWm2my0PyomJsy8+cMB4KmcYRlslipahFKO5nwf+PzrBZU5 Z+5Q==
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 :message-id:references:to; bh=zlCl7CPkR3JE/qFRMSkbdPR9LQSCNqQkG+ewcxOchjU=; b=CLbS5rOgN+/QjcVvx2LwMCdePpQficT88FT4DyJFKfDAL98Qh0xxodiInDJZPJtyb3 v2xSch1U2lW/uckv/Gg0Grl8pq5iFa+b+iyniqs4f4WGnhbqNznBKvPvch5qR8Qq2xuR 7DRcE0itfHQ8izYBKmzBhQCy8onadlBtF72mNmi2gXHRhhlBdVQPLF3XW9WFFkI/sJSO Aj6mIb2/9A/RSFpBHTQPdlBmG7dOvOAWH7SFbFLM/AwjgiLRC8M/rAmuu3sq+FVpWYyb Ckr4owR+sxB4iGTEAg5dMPrz7J70LSEc0uj9tFTxqJaFuOxflHzWVxEmQG7PV+BwfYT4 5zmQ==
X-Gm-Message-State: AA6/9RniEEpmQY+Y5r8aoEyV3Q7jZkTa+3tHV0xHB096KV08jlZGSwvjSVUqwOHzF36P5Q==
X-Received: by 10.66.191.135 with SMTP id gy7mr13696940pac.21.1474839468424; Sun, 25 Sep 2016 14:37:48 -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 ra13sm25669683pac.29.2016.09.25.14.37.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 14:37:47 -0700 (PDT)
Content-Type: multipart/mixed; boundary="Apple-Mail=_DF123D10-5132-4803-B280-F98BC2FA86DA"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <57E690AD.2030207@gmail.com>
Date: Sun, 25 Sep 2016 14:37:45 -0700
Message-Id: <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com>
References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com>
To: Chris Lonvick <lonvick.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/bgy-ua-AFyqaa_3rRBQZUtfANSo>
Cc: draft-ietf-lisp-crypto.all@ietf.org, "iesg@ietf.org" <iesg@ietf.org>, Dino Farinacci <farinacci@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07
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: Sun, 25 Sep 2016 21:37:57 -0000

> Cut-n-pasted wrong. Resending.
> Thanks,
> Chris

Thanks Chris, glad you did since I didn’t see the original.

>> Hi Dino, Brian, and All,
>> 
>> 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.
>> 
>> The document is acceptable for an Experimental RFC. 

Okay, great.

>> I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the 

Yes, there is. If the Map-Reply this is returned contains no Security LCAF that means to the ITR that it either needs to go unencrypted encapsulating packets to the ETR or try another cipher text.

>> draft. You should address this in a future draft. This will be needed for when new cipher suites are 

Understand the need. We intentionally wanted to support this.

>> added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this.

We have this in section x of the draft. Is it not sufficient?

   If an ITR, PITR, or RTR sends a Map-Request with the Security Type
   LCAF included and the ETR or RTR does not want to have encapsulated
   traffic encrypted, they will return a Map-Reply with no RLOC records
   encoded with the Security Type LCAF.  This signals to the ITR, PITR
   or RTR not to encrypt traffic (it cannot encrypt traffic anyways
   since no ETR public-key was returned).

>> There are a few nits in the draft you may want to take care of. First, Section 6 talks about setting the R bit to 0. 
>> Current:
>>    The 'R' bit is not used for this use-case of the Security Type LCAF
>>    but is reserved for [
>> LISP-DDT
>> ] security.  Therefore, the R bit is
>>    transmitted as 0 and ignored on receipt.
>> 
>> Proposed: 
>>    The 'R' bit is not used for this use-case of the Security Type LCAF but is 
>>    reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be transmitted 
>>    as 0 and MUST be ignored on receipt. 
>> 
>> A few other things I found:
>> s/assymmetric/asymmetric/ 
>> s/Soon as an ETR or RTR/As soon as an ETR or RTR/ 
>> s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and finally key-id 3/ 
>> 
>> Best regards,
>> Chris

All fixed. I did not submit -08 because I wanted to see if you thought the paragraph above was sufficient. A diff and txt file in enclosed.

Thanks again,
Dino