Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <57EB1C33.60000@gmail.com>
Date: Tue, 27 Sep 2016 18:28:56 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF20FC80-A83A-4621-BF0B-8C11273B482A@gmail.com>
References: <57E68FB7.10408@gmail.com> <57E690AD.2030207@gmail.com>
 <65A320B3-F8AD-461B-8F4B-1EF029E538DD@gmail.com> <57E87980.2050209@gmail.com>
 <7345DDFF-0D4F-4F47-87D1-56459ED94D2A@cisco.com>
 <067010BC-5EE7-46AF-B06F-B227BEE9A565@gmail.com> <57E95D87.4090104@gmail.com>
 <57EB1C33.60000@gmail.com>
To: Chris Lonvick <lonvick.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/otEr3-NrZUW13mNsmqqszvR2RAA>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-lisp-crypto.all@ietf.org"
 <draft-ietf-lisp-crypto.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-crypto-07
Precedence: list

Thanks. I will post -08. Thanks.

Dino

> On Sep 27, 2016, at 6:26 PM, Chris Lonvick <lonvick.ietf@gmail.com> =
wrote:
>=20
> Resending - Looks like Dino didn't get this.
>=20
> Best regards,
> Chris
>=20
> On 9/26/16 12:40 PM, Chris Lonvick wrote:
>> Hi Dino and Brian,
>>=20
>> 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.
>>=20
>> Best regards,
>> Chris
>>=20
>> On 9/26/16 11:47 AM, Dino Farinacci wrote:
>>> Chris, if you are fine with Brian=92s response, I can post the -08. =
Please ack. Thanks.
>>>=20
>>> Dino
>>>=20
>>>> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) <bew@cisco.com> =
wrote:
>>>>=20
>>>> Hi Chris,
>>>>=20
>>>> Thanks for the review. I=92ve added one comment below.
>>>>=20
>>>>> On Sep 25, 2016, at 6:27 PM, Chris Lonvick =
<lonvick.ietf@gmail.com> wrote:
>>>>>=20
>>>>> Hi Dino,
>>>>>=20
>>>>> 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.
>>>>>>=20
>>>>>>>>>> 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.
>>>>>>=20
>>>>>>>>>> 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?
>>>>>>=20
>>>>>>   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).
>>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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. =46rom 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.
>>>>=20
>>>> Thanks,
>>>> Brian
>>>>=20
>>>>> Best regards,
>>>>> Chris
>>>> --=20
>>>> Brian Weis
>>>> Security, CSG, Cisco Systems
>>>> Telephone: +1 408 526 4796
>>>> Email: bew@cisco.com
>>>>=20
>>=20
>=20