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

Dino Farinacci <> Sat, 22 October 2016 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CA3B1295E5; Sat, 22 Oct 2016 11:18:02 -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 FCXEwk_LpsZm; Sat, 22 Oct 2016 11:18:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18EA812944D; Sat, 22 Oct 2016 11:18:01 -0700 (PDT)
Received: by with SMTP id s8so74725778pfj.2; Sat, 22 Oct 2016 11:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1fQxj5f8UEr0voo6Xm/nuX/Lb7B6yz7ZtQRRuZxGNk=; b=GZQ5bzWvO82VOq46mXQPDa0bT7Mcr1sRaVqwU/0wacVaNYnZGnHMjfYZA9JK73c4V4 L4wSNjMllAbWVdlUMCRJ/94jIsbhZwwkyiW7+GcIV0R1oDLdYg/C/sbjDQvgQsIBcyWV iHaUx6+rtFWD0gTeGxgldz0b0gMgCaFioyhxKXMMoHmll3n5Jtqlgy9HjcCVy1ArqsfD hgN3ZKc7KA8OWuubTmX4Fb8q4bolSmka4H+mR+i7bnjKa8ohROAnwhzDyguosDuN5vXo NVND1kvIi0JLMqI7ua3jdt1ME1qF5itBOVj1Qac954o0qowvNRvuPb0LAeubr5QgEn1u u/3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q1fQxj5f8UEr0voo6Xm/nuX/Lb7B6yz7ZtQRRuZxGNk=; b=IIEfjTEPuPoC8qZNhzZiHgVMo6aJ9gqEqwSZqPw6Ps33znic9Lyu6MSRwhFjztwsbI ArJx65HUx4AXPpu27vdo4ie+RgQEZvTR8LSLO4xGx7Z612NgETHITwTj01y2Bb5Jes2n 88TbSecQQaAvYgrK3o8gqpBI/WK3IKboCPVaGRTg3UOBhYH2dlshJ7Vcih8ra1jiIbai 6GLRgmmCZwEEpOZlLfpdAcLPL755dPpEZCy9rF6+vUk5hRa7/WxmUWM70ItjkN9Op7er K52qiULpKRbo3vDM/QV29fGGWIpIJpc5eTU7Kck+l3H2UhAX7LpZ49OTpBOihOzJzzo6 rRIw==
X-Gm-Message-State: ABUngve+u+xgKtztIjR0xv7b4wnRh+564i0Dw25+bXnMddAIOtrKUPsu67SnlI0/s28DGw==
X-Received: by with SMTP id m12mr11005985pgd.45.1477160280667; Sat, 22 Oct 2016 11:18:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id h8sm13892897pab.9.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 22 Oct 2016 11:18:00 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Dino Farinacci <>
X-Mailer: iPhone Mail (14A456)
In-Reply-To: <>
Date: Sat, 22 Oct 2016 11:17:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "Brian Weis (bew)" <>
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: Sat, 22 Oct 2016 18:18:02 -0000

> 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

Well as you know the lisp-crypto cipher suites use AEAD so there is mechanism, we'd just need more detail here. 

> that the PIM peer is authorized. If authorization of the peer is not needed, then no problem. But if you expected to

Well we have to start out as an open system so any ETR is allowed to join an ITR for an (S,G). Having it authorized to do so can be done by the mapping system. If the mapping system doesn't return the RLOC of the ITR for any ETR, they can't join. 

> (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 

Right I was referring to the control plane where joins would normally be unicast. 

> 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.

Not trying to solve that. Right now if you want multicast to be encrypted, you do that with replicated unicast, where the ITR uses different keys and key-IDs for each packet being unicast encapsulated to each ETR.