Re: [secdir] Secdir last call review of draft-ietf-lisp-sec-13

Fabio Maino <fmaino@cisco.com> Tue, 24 October 2017 17:16 UTC

Return-Path: <fmaino@cisco.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 562BA13955E; Tue, 24 Oct 2017 10:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 A1ieShkQjZBY; Tue, 24 Oct 2017 10:16:42 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FC913954E; Tue, 24 Oct 2017 10:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2692; q=dns/txt; s=iport; t=1508865402; x=1510075002; h=from:subject:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+LV4/1v9fQxWHVlEe9RoD0erksF+JaruzAUoDXFJ56E=; b=Qg+7bKAhKChZ9zAfve/cVUZ/DvO2qoc2hwrMvtuEg3Y0dFp5Xt9FC+in PjrivPySWWb25U70Am0iIxoUb2uaQ4iJImkMSWLuM0yqM6gXeFnfC3Qhw 7bLYBeOnFqcuTiy2/Y8B/gHE/jblDbmS05T3mHdmpBEtfNREw49zDDF/I o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CiAAAEde9Z/4ENJK1bGQEBAQEBAQEBAQEBBwEBAQEBg1+BUoQhih+PSYFUJnuVP4IRCoU7AoRhPxgBAgEBAQEBAQFrKIUdAQEBAQIBIw8BBUEFCwsYAgImAgJXBgEMCAEBihQIqB6CJ4shAQEBAQEBAQEBAQEBAQEBAQEBIIEPgh+BKl2BUIFpKQuCQTWIGYJhBZJjjwqUdYIVhXqDXSSHFZV/gTkfOIFbNCEIHRWDLoJbHIIHIIwnAQEB
X-IronPort-AV: E=Sophos;i="5.43,428,1503360000"; d="scan'208";a="21555998"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Oct 2017 17:16:41 +0000
Received: from [10.155.69.231] (dhcp-10-155-69-231.cisco.com [10.155.69.231]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v9OHGb1k006413; Tue, 24 Oct 2017 17:16:40 GMT
From: Fabio Maino <fmaino@cisco.com>
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, secdir@ietf.org
Cc: draft-ietf-lisp-sec.all@ietf.org, ietf@ietf.org, lisp@ietf.org
References: <150764751351.13466.15119625109787574982@ietfa.amsl.com>
Message-ID: <77a18485-6759-5d24-de52-27f76a7d3837@cisco.com>
Date: Tue, 24 Oct 2017 10:16:38 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150764751351.13466.15119625109787574982@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/j7vjOG0dtki_421wTa9wHETiCK0>
Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-sec-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 24 Oct 2017 17:16:43 -0000

Hi Takeshi,
thanks for taking the time to review the document.

Please see below for comments. Unless you have objections we plan to 
publish an updated rev by monday.

On 10/10/17 7:58 AM, Takeshi Takahashi wrote:
> Reviewer: Takeshi Takahashi
> Review result: Ready
>
> 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.
>
> I would say this document is ready with nits, but the nits are very minor.
>
> [comments that require chages to the current draft]
> 1. I guess the authors mix up "reply" and "replay" in Section 6.6. "Reply
> attacks" could be "Replay attacks".

fixed, thanks!

> [comments that does not necessarily require changes to the current draft]
> 2. The security aspect of LISP is addressed not only in this draft but also in
> RFC6830 and in RFC7835. If I understood correctly, LISP-SEC addressed a part of
> the threats mentioned in RFC7835. Then, it would be nice if the authors could
> clarify what types of further threats that are not mentioned in LISP-SEC still
> exist by referring to RFC6830 and RFC7835.

Section 3 of LISP-SEC provides the cross references with the threat 
model of RFC 7835. LISP-SEC focuses particularly on the threads 
described in section  3.7 and 3.8 of RFC 7835 that describes attacks 
that "target EID-to-RLOC mappings, including manipulations of 
Map-Request and Map-Reply messages, and malicious ETR EID prefix 
overclaiming."

We should change the first sentence of section 3 to read:
"LISP-SEC addresses the control plane threats, described in *Section 3.7 
and 3.8 of* [RFC7835], that target EID-to-RLOC mappings, including 
manipulations of Map-Request and Map-Reply messages, and malicious ETR 
EID prefix overclaiming."


> 3. DOS/DDoS was mentioned in the introduction section, but it was not discussed
> in the later sections. It would be nice if the authors could address DoS/DDoS
> issues as well.
>
>

Good point. We should add a Section 6.7 that reads:

"6.7 Denial of Service and Distributed Denial of Service Attacks

LISP-SEC mitigates the risks of  Denial of Service and Distributed 
Denial of Service attacks by protecting the integrity and authenticating 
the origin of the Map-Request/Map-Reply messages, and by preventing 
malicious ETRs from overclaiming EID prefixes that could re-direct 
traffic directed to a potentially large number of hosts."


Thanks,

Fabio