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

Chris Lonvick <> Wed, 28 September 2016 01:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B018512B3A7; Tue, 27 Sep 2016 18:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gg9vudPiALbj; Tue, 27 Sep 2016 18:26:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5C9312B3A1; Tue, 27 Sep 2016 18:26:14 -0700 (PDT)
Received: by with SMTP id l25so11415177pfb.1; Tue, 27 Sep 2016 18:26:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XhUSxczEkA4LX0l2Ab7C0OrE5p2+2CTAayTyytXi+FE=; b=glORpHnltExOXfB5+O1JaOXQ6zczT6r3FInNbTGfZDHXx1tYZAmzhkliCoZSSsizSi cTkZJ/y+x8Ck9IIHBikNhHbH5LJp5In09tGNQCba56DpcbFu45nKgAy7dYgl5EqdDPks C8x0SRffP1cHZxIVjVJ8NSI4kE9Nktdgiv35JmWPUiGRE3qDM8ZGXT3hIpUsz4ay94A7 ZCAJ63oYL8wPc4dfPP1awhn/+3OTxHfUYjOoYqCGHp9Obz9XMcC1jYzl6ZVhkCzrSanR LlwPlcF7A5Yi6jey0At0pp+H7FQ+w8yjdb1eXKcnnThCI29Negj1QL2rFwa3QgvRHiY5 v5nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XhUSxczEkA4LX0l2Ab7C0OrE5p2+2CTAayTyytXi+FE=; b=VYHfy4BH/aVoKYvPZRBn122yZLC/ufm/p4gtWT6JSA61dp5cL2+2ReSLWNLNYr3uOW Z0A5tkVYfKToBO+Pr4/vH3VWl4Adto8GuDntfra1h5KUVol1Cz8fOS5rfVlZ6duTXJOW uBi+f6Qi7bvvXN5tWH9/ufYlqIMCNPXb7uNkB6HruX0LxOO/NUVspmhUGfKHmVBSQAx7 ST1EIZyAOvskkb+klL4Df4U/BhxiMU8HFmCiFQFy0rqTCTLEdsEDz11fc6nAFQrVlYFB AyYCItoqK79s318JAoNOXWvPGNJ4vdATbGw6AdmqsxdxkEghn58xjikn9GzPurKHKKDc 2tlg==
X-Gm-Message-State: AE9vXwONgKLdHUrGrhMFwlkhcuaHkwDMG28he6ItxNZVD5tfFir0hkaaglHGha6UxuuTHQ==
X-Received: by with SMTP id d10mr52116094pfk.8.1475025974363; Tue, 27 Sep 2016 18:26:14 -0700 (PDT)
Received: from ([2602:306:838b:1c40:b47b:b432:d33f:ea09]) by with ESMTPSA id s82sm7577954pfg.42.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Sep 2016 18:26:12 -0700 (PDT)
To: Dino Farinacci <>, Brian Weis <>
References: <> <> <> <> <> <> <>
From: Chris Lonvick <>
Message-ID: <>
Date: Tue, 27 Sep 2016 20:26:11 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07
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: Wed, 28 Sep 2016 01:26:17 -0000

Resending - Looks like Dino didn't get this.

Best regards,

On 9/26/16 12:40 PM, Chris Lonvick wrote:
> Hi Dino and Brian,
> Yup - all looks good. I didn't mean to push too much on the point 
> because I figured that it wasn't needed or wanted for being an 
> experimental document. Good luck with it.
> Best regards,
> Chris
> On 9/26/16 11:47 AM, Dino Farinacci wrote:
>> Chris, if you are fine with Brian’s response, I can post the -08. 
>> Please ack. Thanks.
>> Dino
>>> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) <> wrote:
>>> Hi Chris,
>>> Thanks for the review. I’ve added one comment below.
>>>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick <> 
>>>> wrote:
>>>> Hi Dino,
>>>> On 9/25/16 4:37 PM, Dino Farinacci wrote:
>>>>>>> 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).
>>>> That text just says that if the cipher suite is declined then there 
>>>> will be no encryption. I was interpreting that to mean that the 
>>>> receiver just isn't going to accept any attempt at encryption. If 
>>>> it's just meant to be for that particular cipher suit then you'll 
>>>> need to add a line to that paragraph to say that the ITR, PITR, or 
>>>> RTR can attempt a different cipher suite if it is administratively 
>>>> configured to do so. However, that could get to be very inefficient 
>>>> if the ITR has to make 6 attempts before understanding that the ETR 
>>>> just isn't going to accept any encryption request - if it's so 
>>>> configured, or if it just doesn't support the feature whatsoever. 
>>>> So even if you allow the sender to make offer after offer, it would 
>>>> still be a good idea to have a way for the receiver to entirely 
>>>> decline encrypting packets from the sender.
>>>> But, with all that being said, I'm figuring that we're getting 
>>>> outside the intent of your experimental specification. When you do 
>>>> get around to getting this onto a standards track, then you should 
>>>> make some decisions around how to convey capabilities between the 
>>>> sender and receiver so they can quickly and efficiently figure out 
>>>> what's going to work, or if it's just not, rather than making one 
>>>> offer after another. TLS and SSH have ways for a sender to offer a 
>>>> list from which the receiver can choose, if you're looking for 
>>>> examples. Another way is for the sender to proffer a version number 
>>>> which is associated with a select group of capabilities. From that, 
>>>> the receiver can make a choice, or efficiently decline all.
>>> Thanks for the suggestions. In this effort we were intentionally 
>>> avoiding the complexities and added security analysis requirements 
>>> of a multiple round-trip method capabilities negotiation such as 
>>> TLS. But maybe a capabilities declaration more along the lines of 
>>> the version number you suggest might be appropriate.  I agree that 
>>> at such time as the protocol was prepared for standards-track that 
>>> this would be important to add.
>>> Thanks,
>>> Brian
>>>> Best regards,
>>>> Chris
>>> -- 
>>> Brian Weis
>>> Security, CSG, Cisco Systems
>>> Telephone: +1 408 526 4796
>>> Email: