Re: [secdir] SecDir review of draft-ietf-pim-join-attributes-for-lisp-05

"Brian Weis (bew)" <> Fri, 21 October 2016 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 113B8129644; Fri, 21 Oct 2016 14:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.952
X-Spam-Status: No, score=-14.952 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, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IcWTcax9Ubg9; Fri, 21 Oct 2016 14:19:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F92D129640; Fri, 21 Oct 2016 14:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2624; q=dns/txt; s=iport; t=1477084777; x=1478294377; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Bd/pPoA3dloVJqnUAgULNo9VFhIRFs5QC2b7752zaQ0=; b=jYsVklnoztxHjllK1UlRaR8VQO7x4SnghIljFm484aQ6MDt81wvd2iGW MrXhiYugGyrayrXbOhyH2MT5phFNWLKbFVX8oEw5PQHyt4vk88sxFP0EI qpMFWD2sq7n3AwHiJl4K5yB+mn7dlSfkpZtY5TPnzpSJfbMfx+Iyp8CR4 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,526,1473120000"; d="scan'208";a="336892006"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2016 21:19:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u9LLJaJE031209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Oct 2016 21:19:36 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Oct 2016 17:19:35 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 21 Oct 2016 17:19:35 -0400
From: "Brian Weis (bew)" <>
To: Dino Farinacci <>
Thread-Topic: SecDir review of draft-ietf-pim-join-attributes-for-lisp-05
Thread-Index: AQHSK8O+bD4Oo8T4K0G94NzRLPhqbqCzdn2AgAA2rQA=
Date: Fri, 21 Oct 2016 21:19:35 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] SecDir review of draft-ietf-pim-join-attributes-for-lisp-05
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: Fri, 21 Oct 2016 21:19:39 -0000

Hi Dino,

> On Oct 21, 2016, at 11:03 AM, Dino Farinacci <> wrote:
>> These new attributes are all delivered in PIM messages, which are sent encapsulated in LISP, and if a user has chosen to protect the LISP traffic across the provider network for confidentiality or privacy reasons, and/or chosen to protect the PIM packets with an integrity method, then the new attributes will also be protected. The information in the attributes related only to delivery of the packets, and there are no particular privacy considerations. The current Security Considerations section seems adequate.
> Yes, using lisp-crypto. But do you think different keying should be used for data versus control traffic?

I don’t think they necessarily need to be keyed differently. I expect that the xTRs are trusted to are distribute both data and control traffic to the same peers.  But there are some considerations to using lisp-crypto for this:

(1)  Since lisp-crypto doesn’t actually authenticate the peer (i.e., it’s intent was for privacy of data) then there’s no guarantee that the PIM peer is authorized. If authorization of the peer is not needed, then no problem. But if you expected to restrict the flow of LISP encapsulated data then once should use an encryption method that includes authentication of the peer.

(2) If both flows are purely unicast then lisp-crypto can be used, but since lisp-crypto is Diffie-Hellam based only two xTRs will know the key. When LISP packets are sent as native multicast packets across the provider network there are likely multiple receivers, all of which need the same session keys as the sender. One would need to use something like GDOI (RFC 6407) to distribute a group key to the xTRs to protect the data traffic.


> Dino

Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796